DEV Community: Anton Nesterov

Building a feature-rich datagrid with Deno & Preact - First Impressions

Anton Nesterov — Wed, 19 Nov 2025 14:05:58 +0000

I think most of the full-stack devs would agree with me when I say that developing anything related to datagrids is a challenging task with or without coding agents.

Recently I had an idea that involves agents and tool calling in datagrid interfaces - surpise ;). And after extensive research found out that most of the opensource datagrids wouldn't work for what I want to create. The kind of situation when either it is not scalable enough or it would require to rewrite it anyway.

So I've decided to create my own datagrid. A perfect opportunity to create something w\o legacy bagage and use Deno in a serious project. And also Preact is something I wanted to use in a real project but never had a chance.

So what can I say? In my opinion Preact and Preact Signals are severely uderrated among the devs. I think it's a brand issue - Preact, you should re-brand. Preact with signals is more than "just react alternative" Seriously, if you're able to see past boilerplates in react tutorials you should try it.

Deno is as good as advertised. Especially for 0-legacy projects. I watched Deno projects for a couple years and experimented with it a lot. Only good impressions so far.

About my datagrid. If you previously developed feature-rich data tables you understand the challenges. If not, you should know that it's not as simple as it seems.

The project itself is currently pre-alpha, but it is live and clickable. Most features are in the context menu and currently most feature-rich instance is here: https://table.vski.ai/flat (also supports standard key bindings [cmd+/] instruction mode)

Github: https://github.com/vski-ai/table , it is not fully opensource because no one knows about it yet and I am not sure there are people or companies who would take much interest in yet another "just a table" component.

A take on Go Style Error Handling in JavaScript

Anton Nesterov — Wed, 16 Oct 2024 08:24:45 +0000

Almost everyone who uses JavaScript daily knows that try-catch can be painful to deal with, especially when you have more than one error to handle.

Most proposed solutions are tryng to copy Golang's approach - which handles everything as return values. It is, among other things, is a great feature of Go, but JS is completely different language (duh) and I think we can do better than a copy-paste from Go.

In Go, when we want to handle an error, we return it from the function call either as a second value in tuple or as return value of the function call. Following is the pattern:

result, error := DoSomething()
if error != nil {
 // handle error
}

This approach allows to handle the errors explicitly using standard control flow.

To apply this pattern in javascript the most common solution is to return results as an array:

const handler = async (promise) => {
  try {
    const result = await promise()
    return [result, null];
  } catch(error) {
    return [null, error];
  }
}

const [response, error] = await handle(fetch('http://go.gl'))
if (error !== null) {
  // handle error
}

As you can see this is almost direct copy-paste of the pattern from Go.

Returning consistent value

This pattern works great, but in javascript we can do better than this. The core idea of this pattern is to return error as a value, so let's adapt it with better SoC.

Instead of returning null or Error we can decorate the result with a consistent interface. That would improve our SoC, and give us a strongly typed return value:

interface Status {
  Ok(): boolean;
  Fail(): boolean;
  Of(cls: any): boolean;
}

The interface Status doesn't have to be an Error, but we can check it's type using status.Of(Error). We can always return an object that sattisfies Status. The usage example would be:

const [response, error] = await handle(res.json())
if (error.Of(SyntaxError)) {
  // handle error
  console.log("not a json")
  return
}

Now, in JavaScript our result doesn't always have to be a tuple. We can actually create our own class that behaves as a tuple when it's needed:

interface IResult<T> {
  0: T;
  1: Status;
  value: T;
  status: Status;
  Of(cls: any): boolean;
  Ok(): boolean;
  Fail(): boolean;
}

Usage example:

const result = await handle(res.value.json())
if (result.Of(SyntaxError)) {
  // handle error
  console.log("not a json")
  return
}

The Implementation

Following this approach I've created ready to use function - Grip.

Grip is strongly typed and can decorate functions and promisises alike.

I use git to host such packages, so to install use github:

bun add github:nesterow/grip # or pnpm

Usage:

The grip function accepts a function or a promise and returns a result with return value and status.
The result can be hadled as either an object or a tuple.

import { grip } from '@nesterow/grip';

Handle result as an object:

The result can be handled as an object: {value, status, Ok(), Fail(), Of(type)}

const res = await grip(
  fetch('https://api.example.com')
);

if (res.Fail()) {
    // handle error 
    return;
}

const json = await grip(
  res.value.json()
);

if (json.Of(SyntaxError)) {
    // handle parse error 
    return;
}

Handle result as a tuple:

The result can also be received as a tuple if you want to handle errors in Go'ish style:

const [res, fetchStatus] = await grip(
  fetch('https://api.example.com')
);
if (fetchStatus.Fail()) {
    // handle error
    return;
}

const [json, parseStatus] = await grip(
  res.json()
);
if (parseStatus.Of(SyntaxError)) {
    // handle parse error
    return;
}

Handle functions:

Grip can also handle functions:

const [result, status] = grip(() => "ok");
// result = "ok"

const [result1, status1] = grip(() => {
  if (1) throw new Error("error")
});
// result1 = null
// status.Of(Error) = true

Handle generators

Generators can be handled using the Iter() method:

const res = grip(async function* () {
  for (let i = 0; i < 3; i++) {
    if (i == 2) throw new Error("2");
    yield i;
  }
});
for await (let [value, status] of res.Iter()) {
  if (status.Of(Error)) {
    // handle error properly
    break;
  }
  // typeof value === "number"
  console.log(value)
}

If you like this take on error handling check out the repository. The source is about 50LOC, without types, and a 100 with types.

BunJS Is Indeed Faster than NodeJS

Anton Nesterov — Sun, 01 Sep 2024 20:37:22 +0000

I have a dirty secret - I use Bun instead of NodeJS for my own projects.

I use it because of a better developer experience and other good features.

I always take someone's claims about better performance with a grain of salt. The benchmarks and any other comparations are as much a marketing tool as anything else, especially when you don't have time to check those claims yourself. In my case I had a chance to compare Bun performace myself and I can confirm - Bun is faster than NodeJS.

If you did more or less JavaScript you probably know that the Garbage Collector is one of the top reasons of hight CPU usage and it contibutes a great deal in application performace downgrade. It is especcially true for any high loaded services, and this is usually the main reason why engineers sometimes resort to rewriting their work in other languages. This is not in particular a "javascript" problem, any garbage collected language has its own patterns to mitigate GC spikes.

Recently I had to write a test for my pet project in development DAL (Data Access Layer) to check for possible memory leaks. DAL is a proxy for relational databases and it is written in Go, which is also a garbage collected language. Initially it was written in NodeJS, but some time ago I've decided to refresh the codebase and rewrite it in Go for various reasons. And for the sake of backward compatibility with older versions I have also decided to explore the ways to integrate DAL into nodejs process, and because I use Bun, I couldn't miss the oppotunity to check their FFI interface.

Marrying Golang and JS wasn't a challenge. A simple C++ glue in NodeJS case, and FFI/dlopen in Bun's case. The main thing I am watching for is possible memory leaks. It is easy to miss some pointer during development and then the whole thing is destined to crash.

Testing Methology

In order to check for the memleaks I wrote a benchmarks that spams my library with a 100M (100 000 000) simple queries which is about 10Gb of data transfer. The benchmark tracks process' memory, and if we have a leak - the difference between RAM usage on starutup and at the end of execution would be great. The benchmark also gives an oppotunity to check how well GC is performing under the load.


OS	Mac OS, ARM64
Device	MacBook Air M2
RAM	24Gb
DB	SQLite 3, WAL mode
NodeJS	v20.10.0
Bun	v1.1.25

Following query is encoded to message pack format and passed to the builder method using native bindings:

instance
    .In('table')
    .Find({
        a: 1,
        b: {
            $gt: 2,
        },
    })
// SELECT * FROM table WHERE a = 1 AND b > 2  ;

The database responds with an error message, so we don't read anything from the disk.
The test's purpose is to check for the leaks and measure performace.

Metrics

Process memory at Start
Process memory at N iteration
Average memory at the End
Time to end

Full benchmark source can be found here.

bun bench:node #npm run bench:node
bun bench:bun

The main differences

Bun opens the shared library (dylib) and allocates it in the extenal memory.
NodeJS uses NAPI - C++ binding is slightly diiferent but uses the same methods.
Both implementations work the same way and free unused memory manually when required.
Bun did not require to write C++ glue, it provides an FFI interface.

NodeJS Performance

START
  rss: 32 Mb
  external: 1 Mb
  buffers: 3 Mb
  total: 4 Mb

Data transfered:  11539 Mb
Time to end: 1:16.586 (m:ss.mmm)

AVERAGE:
  rss: 51 Mb
  external: 2 Mb
  buffers: 4 Mb
  total: 6 Mb

Observations:

High CPU usage (top - ~120%)

Bun Performance

START
  rss: 37 Mb 
  external: 0 Mb 
  buffers: 0 Mb 
  total: 2 Mb 

Data transfered:  11539 Mb
[46.25s] Time to end

AVERAGE:
  rss: 82 Mb
  external: 25 Mb
  buffers: 29 Mb
  total: 22 Mb

Observations:

High CPU usage (top - ~101%)

The Result

Runtime	RSS START	Average Memory at Runtime	Time To End
NodeJS	32Mb	51Mb	116sec
Bun	37Mb	82Mb	46sec

Even though Bun allocated more memory at runtime, the execution time of the same script was 2.5 x faster than in NodeJS (46sec <> 116sec).
For myself, I've concluded that Bun might be cheaper in terms of the cloud costs.

originally published on my blog

I’ve rewritten my JS project in Golang and want to share my experience.

Anton Nesterov — Thu, 22 Aug 2024 01:17:21 +0000

Two years ago I've built for myself a small server in NodeJS - a SQLite proxy over HTTP. It's useful when you have datasets that you need to share with consumers over the network. And after a number of refactors and new requirements, now I have finally decided to rewrite the proxy in Golang for better distribution and memory efficiency. It went so well that I’ve rewritten almost everything in Go even the parts I haven't initially intended to rewrite, and now I believe that 50-70% of what I did before could be better if I used Go along with NodeJS. So, I've prooved to myself that Golang is damn efficient for any backend-heavy web development and almost equal to NodeJS in terms of dev velocity. Even creating a NAPI addons with Go is super easy compared to C++ just because of cross-compilation.

Now let's talk about one Golang shortcoming, and it's not about programming.
For the last year I mostly work as freelance dev. taking gigs and sometimes short contract work. I used Golang ocasionally, mostly when my tasks were related to blockchain, and I've even written couple microservices in Go.

Now I've looked into the job market and I am a bit dissapointed that crypto/finace domain is primary for Golang on the job market :(. And most companies require 3-4 years Go exp (even for gigs), which is hard to get if you don't work for FANG or crypto-finance field.
Golang on the job market seems like RoR for blockchain when I look at my job feeds, kind of "loked in domain language".

If smaller companies and startups also favoured Go, they could've done so many things better, and job market would look differently. I believe that Go can add more value in the products. And yes - one pet project gave me this perspective.

Talking about the pet project.
I present DAL: https://github.com/nesterow/dal

It is in early alpha, because currently only I use it. At the current stage the project can be useful for research, especially for someone who wants to write a native addon for NodeJS or wants to port their libraries to Golang, or to roast me if someone has time :)

The client part is written in TypeScript, the server can be used as standalone binary (best perf) or a nodejs addon.

Peace ✌️

Testable code with VueJS and TypeScript

Anton Nesterov — Wed, 08 Jan 2020 03:38:06 +0000

TL;DR

This is the long text about a 100 lines of code. The result of this tutorial can be found in following repository:

nesterow / nuxt-testable

Nuxt Testable

Whenever I write code, an unit test is always the first debugging tool I use to verify that everything works as intended. Sometimes I catch myself thinking that I cannot imagine development process without writing tests. However, when I work on some projects it is impossible to use TDD, because legacy codebase doesn't follow any good principles (SOLID, GoF) or people who develop it, simply don't know how to write testable code with VueJS. And to my disappointment, I couldn't find any reasonable materials about testing client javascript applications written with VueJS.

In this tutorial, I want to share patterns that help me writing testable VueJS applications. I am going to use NuxtJS typescript template from Nuxt Community, and class-based style for Vue and Vuex components.

Setup environment

1. Generate application skeleton and install dependencies:

~$ vue init nuxt-community/typescript-template vue-testable
~$ cd vue-testable
~$ npm install
~$ npm install vuex-module-decorators
~$ npm install -D @babel/core @types/jest @typescript-eslint/eslint-plugin @typescript-eslint/parser @vue/eslint-config-typescript @vue/test-utils babel-core@7.0.0-bridge.0 babel-eslint babel-jest babel-plugin-dynamic-import-node babel-plugin-transform-decorators eslint eslint-config-google eslint-plugin-nuxt eslint-plugin-vue jest ts-jest vue-jest -D

2. Setup Jest

Open your package.json and add following configuration:

//package.json
{
 //....
 "jest": {
    "testRegex": "(/__tests__/*|(\\.|/)spec)\\.(jsx?|tsx?)$",
    "moduleFileExtensions": [
      "js",
      "ts",
      "json",
      "vue"
    ],
    "transform": {
      ".*\\.(vue)$": "vue-jest",
      "^.+\\.ts?$": "ts-jest",
      "^.+\\.js$": "babel-jest"
    },
    "testURL": "http://localhost/"
  }

}

Open tsconfig.json and add @types/jest to the "types" section:

//package.json
{
 //...
 "types": [
   "@nuxt/types",
   "@nuxtjs/axios",
   "@types/jest"
 ]
}

Also, if the "scripts" section in the package.json doesn't have "test" script, add following:

//package.json
{
 //..
 "scripts": {
    //...
    "test": "NODE_ENV=test jest"
  },
}

2. Setup babel plugins

This is optional, but recommended step. If you're building an universal application you'll find dynamic imports very useful. You might need it to import libraries dynamically only on the client side, because some UI libraries don't care about server environment and reference window and document objects.

Open package.json and add following configuration:

//package.json
{
 //....
 "babel": {
    "plugins": [
      [
        "dynamic-import-node",
        {
          "noInterop": true
        }
      ]
    ],
    "env": {
      "test": {
        "presets": [
          [
            "@babel/preset-env",
            {
              "targets": {
                "node": "current"
              }
            }
          ]
        ]
      }
    }
  }
}

Organising the code

Let's take a pause and consider how we organise the application code.

Application structure so far:

.
├── [assets]
├── [components]
├── [layouts]
├── [middleware]
├── [pages]
├── [static]
├── [store]
├── [types]
├── nuxt.config.ts
├── package-lock.json
├── package.json
└── tsconfig.json

Most people stop at this point and just follow boilerplate defaults. Because the initial application skeleton is self-descriptive you don't have to think where to put a component. And it works whenever you need to create a simple application or a five-pages-site. But what if your application grows to hundreds of views/pages? What if you need most of the views to be customisable enough to move them between projects? How would you achieve this?

Modules

Instead of writing application by boilerplate, I suggest to treat default application structure as an assembly point for independent modules. I mean 'modules' in broader sense than just nuxt modules. In this case a module should fit for any vuex-driven application.

Let's see what would a module structure look like for a Vue/Vuex application. A module should include following entities: components, vuex store, styles, restapi/middleware, type definitions, etc.

Now, we can remove "components" and "middleware" directories from application and add "modules" instead:

.
├── [modules]
|     |
|     └──[module]
|          ├── [__tests__]
|          ├── [components]
|          ├── [store]
|          ├── index.vue
|          └── index.ts
|
├── [layouts]
├── [pages]
├── [static]
├── [store]
├── [types]
├── nuxt.config.ts
├── package-lock.json
├── package.json
└── tsconfig.json

Class-based components.

Writing vue components as classes allows for more sharp and maintainable code. Also, it gives us an opportunity to use inheritance and apply OOP patterns in more concise way.

Following libraries help us to write components in class-based style:
vuex-module-decorators and nuxt-property-decorator. Later we'll see how they work in detail.

Writing a simple app

Let's write a simple todo application. I believe you've done one of those before, but this time instead of jumping right into visual part of the application, we'll do the data model first and start from creating Vuex store. More importantly, we'll begin with writing a specification for our Vuex store. "Specification" is just another word for "test".

During development process, a specification is the first debugging tool. If you had never written a test before, just think about it as of a sophisticated "console.log".

Test Vuex modules

To begin, create a couple new files in our example module: store/todos.ts and store/__tests__/TodosStore.spec.ts.

[modules]
    |
    └──[example]
        |
        ├── [store]
        |      ├──[__tests__]
        |      |        └── TodosStore.spec.ts
        .      └──todos.ts

Let's leave todos.ts with an empty export for now:

// store/todos.ts
export default {}

Add following code to the TodosStore.spec.ts :

// store/__tests__/TodosStore.spec.ts

import Vuex from 'vuex'
import {createLocalVue} from '@vue/test-utils'
import {getModule} from 'vuex-module-decorators'
import TodosStore from '../todos'

const Vue = createLocalVue()
Vue.use(Vuex)

/**
 * Factory function returns a new store instance
 */
const factory = () => {
  const store = new Vuex.Store({
    modules: {
      todos: TodosStore
    }
  })
  return getModule(TodosStore, store)
}

/**
 * The test case
 */
describe('TodosStore', () => {
  it('has to get a store instance', async (done) => {
    const service = factory()
    expect(service).toBeInstanceOf(Object)
    done()
  })
})

SPECIFICATION STRUCTURE

Imports

In order to create a vue exemplar we'll use createLocalVue() from @vue/test-utils
To use Vuex module as a class instance we will use getModule() details

Factory function

A factory function should build and return our testable component. If the factory function is more complex we can put in to a dedicated file.

Test case

Everything you put into describe() should be related to one use case
Unit tests are placed inside it()

RUNNING THE TEST

Let's try to execute the test first time:

~$ npm test

Error:
  Type '{}' provides no match for the signature 'new (...args: any[]): VuexModule<ThisType<any>, any>'.

Test Suites: 1 failed, 1 total
Tests:       0 total
Snapshots:   0 total

The test should fail because we don't yet have our store module in place.

Here is how TDD process goes most of the time:

You write a failing test.
You make the test pass.
You write next failing test and return to step one.

To be realistic, this is not always the case. Sometimes you need to write the test subject before writing the spec, but it doesn't matter if you use the spec for debugging. Also, not everything should be covered by tests - only the parts that affect your program correctness.

Vuex modules

Now, let's make the test pass. At the current state our test should pass simply when we create a complete Vuex module.

USEFUL TIP:

Run npm test -- --watch to run tests automatically whenever you save files.

// store/todos.ts

import {Module, VuexModule, Mutation, Action} from 'vuex-module-decorators';
import {ITodosStore} from './types'

@Module({
  name: 'todos',
  namespaced: true
})
export default class extends VuexModule implements ITodosStore {

}

Don't forget to add type defs as you go:

// store/types.d.ts

export interface ITodosStore {

}

TEST OUTPUT:

 PASS  modules/example/store/__tests__/TodosStore.spec.ts
  TodosStore
    ✓ has to get a store instance (7ms)

After the first test is successful, we can be sure that our store instance is constructed correctly and we can proceed with creating actual application model.

Vuex state and mutations

When you design a data model for you typescript application, the best place to start is the type declaration. Let's declare an interface ITodo which describes structure of a todo item:

// store/types.d.ts

export interface ITodosStore {
  todos: ITodo[]
} 

export interface ITodo {
  id?: string,
  text: string
  timeCreated: Date
  isComplete?: boolean
}

Now, let's specify the methods responsible for changing todos state.
I assume that vuex actions are asynchronous and return a Promise object, when vuex actions are synchronous and should not return anything:

// store/types.d.ts

export interface ITodosStore {
  todos: ITodo[]
  setTodos: (todos: ITodo[]) => void
  pushTodo: (todo: ITodo) => void
  getTodos: () => Promise<ITodo[]>
  createTodo: (todo: ITodo) => Promise<ITodo>
  deleteTodo: (todo: ITodo) => Promise<any>
  setTodoComplete: (opts: {id: string, data: any}) => Promise<any>
} 

export interface ITodo {
  id?: string,
  text: string
  timeCreated: Date
  isComplete?: boolean
}

At this point, if you run the test it would fail due to type errors. Because our store doesn't implement interface ITodosStore as it supposed to. Let's fix it:

// store/todos.ts

import {Module, VuexModule, Mutation, Action} from 'vuex-module-decorators';
import {ITodosStore, ITodo} from './types'

@Module({
  name: 'todos',
  namespaced: true,
})
export default class extends VuexModule implements ITodosStore {
  /**
   * Todos state
   */
  todos: ITodo[] = [];
  /**
   * Todos mutation
   * @param todos: ITodo[]
   */
  @Mutation
  setTodos(todos: ITodo[]) {
    this.todos = todos;
  }
  /**
   * pushTodo
   * @param todo: ITodo
   */
  @Mutation
  pushTodo(todo: ITodo) {
    this.todos.push(todo);
  }
  /**
   * getTodos
   * @returns Promise<ITodo[]>
   */
  @Action
  async getTodos(): Promise<ITodo[]> {
    this.setTodos([])
    return []
  }
  /**
   * createTodo 
   */
  @Action
  async createTodo(todo: ITodo) {
    return todo
  }
  /**
   * deleteTodo 
   */
  @Action
  async deleteTodo(todo: ITodo) {

  }
  /**
   * setTodoComplete 
   */
  @Action
  async setTodoComplete(todo: ITodo, isComplete: boolean) {

  }
}

Testing mutations

Once we've designed store structure, it is time to implement mutations.
We'll start from writing a test:

// store/__tests__/TodosStore.spec.ts

⌃...
it('setTodos', () => {
  const service = factory()
  const todo: ITodo = {
    id: '1',
    text: 'test',
    timeCreated: new Date,
    isComplete: false
  }
  service.setTodos([todo])
  expect(service.todos[0]).toBe(todo)
});
it('pushTodos', () => {
  const service = factory()
  const todo: ITodo = {
    id: '2',
    text: 'test',
    timeCreated: new Date,
    isComplete: false
  }
  service.pushTodo(todo)
  expect(service.todos[0]).toBe(todo)
})
⌄...

This tests should fail because there is a little mistake in our program. If you ran the tests the output of second test would insist that the todo object doesn't match expectation. In fact, the object in the store matches the one we checked in the previous test.
To understand why did it happen, we have to know how javascript imports work and why factory is one of the most commonly used patterns in javascript. The reason it happens is Module caching which helps your program to prevent multiple execution when you import the same dependency into different components. Any time you import something you get the same exemplar from the cache. That's the reason vue requires you to return component's state from a factory method data(). For the vuex store it may not seem something important, but not until you want to build a universal/ssr application where every client app must receive its own instance of global state.

To fix this issue the store state should be built by a factory method. In our case, we need to add the option stateFactory: true to the vuex module:

// store/todos.ts

import {Module, VuexModule, Mutation, Action} from 'vuex-module-decorators';
import {ITodosStore, ITodo} from './types'

@Module({
  name: 'todos',
  namespaced: true,
  stateFactory: true
})
export default class extends VuexModule implements ITodosStore {
⌄...
}

Now the tests should pass and possible cause of bugs is resolved.

Dependency injection

We came to the point where we have to think about communication with the server. The standard application boilerplate suggests to use Axios as a nuxt plugin to make requests. We're going to use axios, but not as a global plugin.

I don't like the idea of coupling such dependencies with vuex store. To understand why, imagine that you want to copy-paste our todo module into another application. Everything would be great if the new environment would use same API. But usually, this is not the case, and your only option is to dig trough the code trying to make it work with new environment. I've seen people performing such tasks with large components, and it didn't seem like something enjoyable.

To avoid such complications our module should depend on an abstract interface rather than on particular axios instance. In the other words - we should be able to configure our store to use different axios instances whenever we need to consume data from different API.

In order to make our modules configurable and abstracted from some dependencies, we use patterns that put into practice Inversion Of Control technique. Such patterns are Dependency Injection or some variations of Provide/Consume (i.e. vue's provide/inject, HoC, etc).

For vue class-based components I've decided to write class decorators which work the same way for Vue components and Vuex modules.

Install provide-consume-decorator library:

~$ npm install provide-consume-decorator

Add Axios

In the store/todos.ts, let's add the api property which references an axios instance. And decorate the class with @provideVuex:

// store/todos.ts
import axios, {AxiosInstance} from 'axios';
import {provideVuex, consume} from 'provide-consume-decorator';
import {Module, VuexModule, Mutation, Action} from 'vuex-module-decorators';
import {ITodosStore, ITodo} from './types'

@Module({
  name: 'todos',
  namespaced: true,
  stateFactory: true
})
@provideVuex({
  axios: ()=> axios.create()
})
export default class extends VuexModule implements ITodosStore {

  @consume('axios') api!: AxiosInstance;

  ⌄...
}

We made it possible to change component's dependencies by replacing one object.

Mocking server

Often, the client application development is ahead of backend. For whatever reason it happens, it is always best when your UI is ready to work with actual http requests. Axios community provides various solutions for mocking http requests so you could re-produce api endpoints locally. This is very useful, but I would suggest to use actual backend service for tests, and mocking only non-implemented methods.

In our case, we can afford mocking entire API on the client side.

The library I found very useful is axios-mock-adapter:

~$ npm i -D axios-mock-adapter

Here is how I wrote a fake API with axios-mock-adapter:

// __tests__/todos.api.mock.ts

import axios from 'axios';
import MockAdapter from 'axios-mock-adapter';
import { ITodo } from '../types';
const $instance = axios.create();
const mock = new MockAdapter($instance);


const todos: ITodo[] = []

/**
 * get todos
 */
mock.onGet('/todos').reply((config) => {
  return [200, JSON.stringify(todos)]
})

/**
 * create a new todo
 */
mock.onPost('/todos').reply((config) => {
  const todo: ITodo = JSON.parse(config.data);
  todo.id = Math.random().toString();
  todos.push(todo);
  return [200, todo]
})

/**
 * update todo
 */
mock.onPut(/\/todos\/\.*/).reply((config) => {
  const id = config.url!.replace('/todos/', '')
  const data = JSON.parse(config.data)
  delete data.id;
  const index = todos.map((t) => t.id).indexOf(id)
  Object.assign(todos[index], data)
  return [200, 'ok']
})

/**
 * delete todo
 */
mock.onDelete(/\/todos\/\.*/).reply((config) => {
  const id = config.url!.replace('/todos/', '')
  const index = todos.map((t) => t.id).indexOf(id)
  todos.splice(index, 1)
  return [200, 'ok']
})

export default $instance;

Let's put it to __tests__/todos.api.mock.ts.

Testing Vuex actions

After we've got a server mock (or actual server) ready, it's time to mate it with our test environment.

In order to use different API with the test, we'll use @provideVuex decorator, only this time we'll supply dependencies for test environment.

Let's open TodosStore.spec.ts and edit our factory function as follows:

// store/__tests__/TodosStore.spec.ts
⌃...
import { provideVuex } from 'provide-consume-decorator'
import apiMock from './todos.api.mock'

const factory = () => {

  @provideVuex({
    axios: () => apiMock
  })
  class TodosStoreMock extends TodosStore {}

  const store = new Vuex.Store({
    modules: {
      todos: TodosStoreMock
    }
  })
  return getModule(TodosStoreMock, store)
}
⌄...

We added a new class TodosStoreMock that extends actual TodosStore. Then we provided a mocked axios instance. It works the same way for any dependencies, for example you could supply another config object or a localStorage for your test.

Now let's implement the actions. And as usual, we'll start from writing a test:

// store/__tests__/TodosStore.spec.ts
⌃...
it('createTodo/getTodos', async (done) => {
  const service = factory()
  await service.createTodo({
    id: '3',
    text: 'test1',
    timeCreated: new Date,
  })
  const todos = await service.getTodos()
  const todo = todos.find((e: ITodo) => e.text === 'test1')
  expect(todo).toBeInstanceOf(Object)
  expect(todo!.text).toEqual('test1')
  // getTodos should also save todos locally
  const localTodo = service.todos.find(e => e.text === 'test1')
  expect(localTodo).toBeInstanceOf(Object)
  expect(localTodo!.text).toEqual('test1')
  done()
})
⌄...

After the test fails, let's create actual API calls in store/todos.ts:

⌃...
  /**
   * getTodos
   * @returns Promise<ITodo[]>
   */
  @Action
  async getTodos(): Promise<ITodo[]> {
    return this.api!.get('/todos').then((res) => {
      this.setTodos(res.data)
      return res.data
    })
  }

  /**
   * createTodo 
   */
  @Action
  async createTodo(todo: ITodo) {
    return this.api!.post('/todos', todo).then((res) => {
      return res.data
    })
  }

  /**
   * deleteTodo 
   */
  @Action
  async deleteTodo(todo: ITodo) {
    return this.api!.delete(`/todos/${todo.id}`)
  }

  /**
   * setTodoComplete 
   */
  @Action
  async setTodoComplete(opts: {id: string, data: any}) {
    return this.api!.put(`/todos/${opts.id}`, {...opts.data})
  }
⌄...

When the tests pass, our todo store is ready!

Consider this: We we didn't connect our store to the nuxt app but we have a strong proof that it works. This is very important when you work with a team, because the specification will also serve as an usage example for other developers.

Writing Vue components

Again, before rushing to the code I suggest to take a break and think how we would communicate with the vuex store inside UI components.

Out of the box, Vuex suggests to access the store trough the global plugin which provides the $store context. But out of the common sense, I don't want our UI depending on particular vuex store implementation. To understand why, imagine that you want to use our UI components in other application which doesn't use Vuex at all.

In order to such level of abstraction we'll make UI components depend on the interface ITodosStore. So if you copy-paste our UI into another vuejs app which doesn't use Vuex, you just need to supply implementation of ITodosStore that fits application architecture.

Here is how we achieve it:

Our parent component (index.vue) will get an instance of ITodosStore and supply it to the children components. There are at least two ways to make it work. First is to use vue's Provide/Inject. The second one is to pass dependencies using component's props. I will use the second approach because in this case it is more explicit, however vue's Provide/Inject might be a better way for more complex applications.

Let's create component backbones in our module directory. We need three components: AddTodo.vue, TodoList.vue, plus index.vue which is our parent component

Directory structure so far:

[module]
    ├──[__tests__]
    └──[components]
    |    ├── AddTodo.vue
    |    └── TodoList.vue
    ├──[store]  
    ├── index.ts
    └── index.vue

components/AddTodo.vue - a children component (consumer):

<template>
  <div/>
</template>

<script lang="ts">
import {
  Component,
  Prop,
  Vue
} from "nuxt-property-decorator"
import { State } from "vuex-class"
import {ITodosStore} from '../store/types'

@Component
export default class extends Vue {
  @Prop() ds!: ITodosStore;
}
</script>

index.vue - the parent component (provider, assembly point):

<template>
  <section>
    <add-todo :ds="ds" />
    <todo-list :ds="ds" />
  </section>
</template>

<script lang="ts">
import {
  Component,
  Vue
} from "nuxt-property-decorator"
import { State } from "vuex-class"
import {provide, consume} from 'provide-consume-decorator'
import { getModule } from "vuex-module-decorators"
import TodosStore from './store/todos'

import AddTodo from './components/AddTodo.vue';
import TodoList from './components/TodoList.vue';

@Component({
  components: {
    AddTodo,
    TodoList
  }
})
@provide({
  //provide a data store
  dataStore() {
    return getModule(TodosStore, this.$store)
  }

})
export default class extends Vue {

  @consume('dataStore') ds!: TodosStore;

}
</script>

Testing vue components

Testing vue components is similar to what did with our Vuex module. However, it requires more configuring. Because now our tests have to use mounted Vue components with connected Vuex store.

We'll write a factory function which returns mounted component with our store module. Also, let's make our factory function reusable, because now we test more than one component.

Create file __tests__/__factory.ts with following content:

import Vuex from 'vuex'
import {createLocalVue, mount, config, VueClass} from "@vue/test-utils";
import TodosStore from '../store/todos'
import apiMock from '../store/__tests__/todos.api.mock'

import { getModule } from "vuex-module-decorators"
import { provideVuex, provide } from 'provide-consume-decorator'
import {Component, Vue } from "nuxt-property-decorator"

export default (VueComponent: VueClass<Vue>, props?: any, attrs?: any) => {

  // store mock
  @provideVuex({
    axios: () => apiMock
  })
  class TodosStoreMock extends TodosStore {}

  // we also provide `dataStore` to components
  @Component
  @provide({
    dataStore() {
      return getModule(TodosStore, this.$store)
    }
  })
  class VueComponentMock extends VueComponent {}

  const localVue = createLocalVue()
  localVue.use(Vuex)
  const store = new Vuex.Store({
    modules: {
      'todos': TodosStoreMock
    }
  })
  return mount(VueComponentMock, {
    props,
    attrs,
    store,
    localVue
  })
}

Here we use @vue/test-utils to mount our component with store and requires props.

Our new factory takes a vue component, then configures vuex module and extends vue component providing required properties. As a result it returns a mounted component instance. Using factories to make code reusable is good practice in general.

Writing a test

Now we write a test for AddTodo.vue. Create __tests__/AddTodo.spec.ts. When I write tests, I always assume that I need to make the spec to look as much "declarative" as possible, because the other developer may need to look inside the spec. It is best when you see the component's options at the top of file.

// __tests__/AddTodo.spec.ts
import factory from './__factory'
import TodosStore from '../store/todos'
import { getModule } from "vuex-module-decorators"

//@ts-ignore
import AddTodo from '../components/AddTodo.vue';

const createComponent = () => {
  const component = factory(AddTodo)
  //props
  const props = {
    ds: getModule(TodosStore, component.vm.$store)
  }
  //reactive data
  const data = {

  }
  //component
  component.setProps(props)
  component.setData(data)
  return component

}

describe("AddTodo.vue", () => {
  it('mounts with store', () => {
    const wrap = createComponent()
    expect(wrap.vm).toBeInstanceOf(Object)
    expect((wrap.vm as any).ds.todos).toBeInstanceOf(Array)
  })
})

The first test checks if the component mounts correctly. In this case, we expect that our component has a property ds (datastore) which provides TodosStore. The success run of this test would ensure that vuex module initialised correctly.

Our component already has the ds property and our first test should pass. So let's create another test and think how our component should work.

TDD and vue components

When you writing an application (not a UI kit) don't make your unit tests to depend on component's markup. Yes, vue test utils provide you with tools to test html markup, but during development, html code updates very often and it can create a lot of routine to maintain the tests. The best way to avoid it, is to write the tests only for javascript context that isn't related to markup. Or to test markup in the way so it doesn't depend on complex css selectors. My approach to this is simple - I don't touch markup in the unit tests, because it is something that you can do much better by hand (using browser). HTML markup can be tested by e2e tests in the pre-release phase (if your company does it).

Back to the code. Now we need to add actual functionality to our component. This is the case, when sometimes I write a method before I write the test. Because designing component's behaviour is more convenient inside the component. So we'll return to our test when we realise how the component would work.

Let's modify our AddTodo.vue component following way:

<template>
  <div/>
</template>

<script lang="ts">
import {
  Component,
  Prop,
  Vue
} from "nuxt-property-decorator"
import {ITodosStore, ITodo} from '../store/types'

@Component
export default class extends Vue {
  //props
  @Prop() ds!: ITodosStore;

  //data()
  text: string = "";

  //getters
  get todo(): ITodo {
    return {
      text: this.text,
      timeCreated: new Date,
      isComplete: false
    }
  }

  //methods
  async create() {
    const todo = this.todo;
    await this.ds.createTodo(todo)
      .then(() => this.ds.getTodos())
    this.text = ""
  }

}
</script>

This component should work as follows: The create() method references this.todo getter which returns an ITodo object, then it posts new todo using an action from the our vuex module. If the action successful we reset this.text. Later, we'll use this.text as a model for a text input. Of course, a real app would need more routine to make a request (loading/error states, try-catch) but in this case it would be enough.

So what we need to verify after we wrote this peace of code? Two things: 1. We need to be sure that our store changed. 2. We have to know if component's state updated.

Writing the test:

⌃...
it('create()', async () => {
  const wrap = createComponent()
  const ctx = wrap.vm as any // as Vue & IAddTodo if want it typed
  wrap.setData({
    text: 'test'
  })
  await ctx.create()
  const todo = ctx.ds.todos[0]
  expect(todo.text).toBe('test')
  expect(ctx.text).toBe('')
})
⌄...

In this test we get components context wrap.vm, then we set reactive data props, and after the request is done we check if datastore is changed and ctx.text reset to initial value. As usual, if the test fails we should make it pass.

Connecting the dots

It is time to connect our module to the nuxt application in order to proceed with UI development.
It is simple, we need to provide our vuex module to the global store and mount our parent component somewhere.

Connecting the store module is usually as simple as importing it to the ~/store/index.ts and adding it to the modules object. But, do you remember that we don't have an actual api yet? During development it is normal to use mocked api. It would be nicer to setup configuration for development environment which would use required entities when we have dev environment, but in this simple case I am going to configure dev. store in place:

⌃...
// ~/store/index.ts

import TodosStore from '~/modules/example/store/todos';

//TODO: apply only for dev environ
import {provideVuex} from 'provide-consume-decorator';
import axiosMock from '~/modules/example/store/__tests__/todos.api.mock'
@provideVuex({
  axios: ()=> axiosMock
})
class TodosStoreMock extends TodosStore {}

export const modules = {
  'todos': TodosStoreMock
}

export const modules = {
  'todos': TodosStoreMock
}
⌄...

For the vue components, we can mount them anyway our vue application allows it. In this case I will mount the component right to the index / route rewriting ~/pages/index.vue:

// ~/pages/index.vue

<script lang="ts">
import {
  Component,
  Vue
} from "nuxt-property-decorator"
import Todos from '~/modules/example'

@Component
export default class extends Todos {

}
</script>

Adding component's markup

Once the nuxt application is set and running, let's see what happens if we add some markup to the AddTodo.vue. My makup looks as follows:

<template>
  <section>
    <input type="text" v-model="text" /> 
    <button @click="create">+ add</button>
  </section>
</template>

Let's test it with the browser and Vue Devtools.

~$ npm run dev

I don't know about you, but my component worked as expected. And usually it works at first try. Notice that it is the first time we launch the browser, a fifteen minutes would pass for me to get to this point if I din't write this post. And this is not a long time considering that at this point we've done more than 50% of the work relying only on unit tests. And now the development process will go much faster.

What next

We have some work left to complete this application. However any further work would be just repeating the steps I described above. So I just share the result in this repository or let you do it yourself if you managed to read whole post.

Cheers!

nesterow / nuxt-testable

Nuxt Testable

Setup minimal kiosk environment with Alpine Linux

Anton Nesterov — Wed, 07 Aug 2019 10:50:57 +0000

In this post I want to share a method of developing kiosk applications for boards like Raspberry PI and analogs.

Why Alpine Linux?

Almost every leading linux distributive provides builds for Raspberry PI. However, most of them come with useless weight especially when you need a system that suppose is to run a single application. Alpine Linux comes in a small size (~130mb) and provides you with simple (but powerful) tools to build your own system.
Alpine is designed to run from RAM, which makes it perfect for creating containers or embedded systems.

You'll need:

Raspberry PI model 3
SD Card, 1GB or more
HDMI Cable
Power source for Raspberry PI
TV or Display with HDMI port
A keyboard
A SSH Terminal application (for Windows users)

Prepare SD Card

No need to flash disk images, installation process is as easy as copying files:

Download Alpine distribution for your model. We need the build for aarch64 architecture. https://alpinelinux.org/downloads/
Format the SD card in Fat32 and make it bootable (Linux, Mac)
Unzip downloaded archive to the SD card alpine-rpi-<version>-armhf.tar.gz

Install Raspberry PI Firmware

Some drivers are not included within the standard Alpine distribution. You need to download them manually.

Open SD card and create directory named firmware
Copy directory called brcm from following repository: https://github.com/RPi-Distro/firmware-nonfree

Now the SD card is ready for Raspberry PI.

First boot

On the first boot Alpine will ask for login. Initially the system has only root user with an empty password.

Welcome to Alpine!

The Alpine Wiki contains a large amount of how-to guides and general
information about administrating Alpine systems.
See <http://wiki.alpinelinux.org>.

You can setup the system with the command: setup-alpine

login: root
...

Run setup script right after the first login:

alpine:~# setup-alpine

The setup process will help to get initial setting right. It is pretty straight-forward and intuitive.

Saving system configuration

Because Alpine runs from memory, all changes you would make to the system is lost after reboot. When you need to save any changes permanently Alpine provides a tool called Local Backup Utility (lbu).

After any significant changes, like editing configuration or installing new software always call lbu commit:

alpine:~# lbu commit

usage: lbu commit|ci [-nv] [<media>]

Options:
  -d    Remove old apk overlay files.
  -e    Protect configuration with a password.
  -n    Don't commit, just show what would have been committed.
  -p <password> Give encryption password on the command-line
  -v    Verbose mode.

Managing software

Package management in Alpine is simple, but slightly different from other distributions.

Updating and upgrading packages:

alpine:~# apk update && apk upgrade

First, let's install nano editor:

alpine:~# apk add nano

Now we need to add APK repositories to be able to install additional software.

Open nano /etc/apk/repositories and uncomment the link pointing to the community repository. The link should look similar to following:

http://mirror.example.com/mirrors/alpine/v3.10/community

Then update package index:

alpine:~# apk update

Don't forget to commit changes after adding new software:

alpine:~# lbu commit -d

Now we're ready to shape the system for our needs.

Configure SSHD

It is more convenient to manage the device from your laptop. Let's setup sshd to be able to open remote shells.

Open nano /etc/ssh/sshd_config and edit it as follows:

PermitRootLogin yes
PasswordAuthentication yes
PermitEmptyPasswords no
DenyUsers guest

Save the file and commit the system configuration:

alpine:~# lbu commit -d

Restart SSH daemon:

alpine:~# service sshd restart

Connect to the device from your desktop:

~#> ssh root@192.168.2.199
password: *********

Install X11

Next step is to setup essential display server and configure Raspberry PI GPU to enable 3D acceleration.

Setup Xorg server:

alpine:~# setup-xorg-base
(1/100) Installing ...

Install video drivers:

alpine:~# apk add mesa-dri-vc4 mesa-egl xf86-video-fbdev xf86-video-vesa xf86-input-mouse xf86-input-keyboard dbus setxkbmap kbd xrandr xset
(1/100) Installing ...

Save changes to the disk:

alpine:~# lbu commit -d

Configure GPU

Raspberry PI doesn't have BIOS, but the essential hardware configuration can be performed through usercfg.txt file.

Insert the SD card and create usercfg.txt with following options:

dtoverlay=vc4-fkms-v3d
gpu_mem=256

Depending on the display model and resolution, you need to modify your settings. All possible options can be found here.

Create user

Now, in order to run kiosk we need to create an unprivileged user. This user will also be used to access the application directory using (SFTP)[https://en.wikipedia.org/wiki/SFTP]

We will keep application files at /srv directory and it also will be the user's home directory.

alpine:~# adduser -h /srv user
alpine:~# chown -R user /srv
alpine:~# chmod 701 /srv
alpine:~# lbu commit

The user's home directory is at /srv, however the files in this directory won't persist until this directory is in LBU index:

alpine:~# lbu add /srv
alpine:~# lbu commit

At last, the user must login automatically on system's boot. In order to achieve this behaviour edit /etc/inittab changing options for tty1:

tty1::respawn:/bin/login -f user

Creating kiosk

Install Chromium browser:

alpine:~# apk add chromium
alpine:~# lbu commit -d

Chromium is going to start after the user login. Let's create two init scripts for this purpose.

Create /srv/.profile file with following content:

#!/bin/sh
# start X server
exec startx

Create /srv/.xinitrc with following content:

#!/bin/sh

# turn off screensaver
xset -dpms
xset s off
xset s noblank


# screen size
width="1920"
height="1080"

# url
url="https://dev.to"

exec chromium-browser $url --window-size=$width,$height --window-position=0,0 --kiosk --no-sandbox --full-screen --incognito --noerrdialogs --disable-translate --no-first-run --fast --fast-start --ignore-gpu-blacklist --disable-quic --enable-fast-unload --enable-tcp-fast-open ---enable-native-gpu-memory-buffers --enable-gpu-rasterization --enable-zero-copy --disable-infobars --disable-features=TranslateUI --disk-cache-dir=/tmp

Make init files executable and commit changes:

alpine:~# chmod u+x /srv/.profile
alpine:~# chmod u+x /srv/.xinitrc
alpine:~# lbu commit

The kiosk is ready! The chromium will start on system boot.
Total image size of this setup is ~235Mb which means you can run an Alpine Linux kiosk from a 256Mb SD card.

What next?

This setup provides pretty simple development environment for your kiosk applications. When developing an application you can point kiosk to a dev. server on your PC to debug and optimise it at realtime. It works well with Webpack and Gulp. In order to upload production builds just use SFTP and lbu commit.

Convenient way to use Babel syntax in Node.JS

Anton Nesterov — Sun, 28 Jul 2019 15:19:27 +0000

When you want to use latest javascript syntax on the server side, typically you are offered two options: babel-node or the --experimental-modules flag.
In this post I want to share another convenient way to use Babel in server applications trough a small library called Pirates

Hijack require

Pirates lets you create your own module loaders for any file types trough a simple API. Among other cool things, It can be used to pre-compile javascript files written with latest ES features.

Consider following example:

const {addHook} = require('pirates');

function matcher(filename) {
  // Here, you can inspect the filename to determine if it should be hooked or not. Just return a truthy/falsey. Files in node_modules are automatically ignored, 
  // TODO: Implement your logic here
  return true;
}

const unregister = addHook(
  (code, filename) => code.replace('@@foo', 'console.log(\'foo\');'), 
  { exts: ['.js'], matcher }
);

// And later, if you want to un-hook require, you can just do:
// unregister();

addHook() accepts two arguments: 1. A parser callback 2. An object with options.

Setting up the project

Let's create an example ExpressJS project with Pirates.

1. Installing Dependencies:

mkdir pirates-test && cd pirates-test
npm init
npm i pirates @babel/preset-env @babel/core express

2. Add Babel hook

Create a file called nodeHooks.js with following content:


const {addHook} = require('pirates')
const {transform} = require('@babel/core')

module.exports = (options) => addHook(
  function(source, filename) {
    return transform(source, {
      presets: [
        [
          '@babel/preset-env',
          {
            modules: 'cjs',
            targets: {
              node: process.versions.node
            }
          }
        ]
      ]
    }).code
  },
  {
    exts: ['.js'],
    ignoreNodeModules: true,
    ...options
  }
)

As you can see the hook function is not so different from a .babelrc configuration.

3. Create an entry point for your application

Now before using Babel in the application we need to register the hook. Right way to do it would be to create an entry point for our application which would load all configurations and register hooks before running the server.

Create index.js with following content:

const registerHooks = require('./nodeHooks')
registerHooks()

// load some configs synchronously 
// then run the server

require('./server')

4. Write the application with Babel

Create server.js with following content:

import express from 'express'

const app = express()

app.get('/', (req, res) => {
    res.send('Hello world!')
})

app.listen(8080)

export default app

Now the entire application can be written with latest ES features.

5. Using nodemon

Use nodemon or your favourite process manager without extra steps:

nodemon index.js

That's about it!

full code

Why they still don't use SVG for landing pages in 2019?

Anton Nesterov — Wed, 24 Jul 2019 11:45:33 +0000

I work at a company with a large web development division. As many other companies in this field, our company has html/css coders to create landing pages by designer's specification.

Recently, I had a need to create a home page for my own project. I asked a designer to draw something simple in vector format. When I've got the result, I was surprised that I don't need to code anything to publish the home page to the web. All work I've done is copy-paste SVG code to the HTML body, and it worked. It worked on any browser I tested it with. The only problem I found so far is that my landing page doesn't have a mobile version. But it is fixable - i just need to add a css media breakpoint for a mobile SVG.

I have to confess I don't have as much experience in web design as in JS development. But I have to raise some questions:

Why not simplify production process for simple static sites and leave this work entirely to Designers?
Are there reasons for people to use html/css in favor of SVG in 2019?

Example on GitHub:
The "code"
The home page itself