DEV Community: Elson Correia

You Are Using the “useState” Hook Wrong

Elson Correia — Mon, 27 Feb 2023 04:25:46 +0000

React API is not developer friendly. One of them is the useState hook which is another misunderstood API much like useEffect .

It looks like this:

const [active, setActive] = useState(false);

At first glance, it does not look like it is doing anything wrong but if you take a look at how React developers use it you may start to see why:

const [active, setActive] = useState(false);
const [loading, setLoading] = useState(true);
const [error, setError] = useState(null);
const [list, setList] = useState([]);

The React documentation hints at the practice of individualizing the state into separate useState and the community went berzerk with it creating components with unnecessary re-renders for a slow app.

The useState hook API mimics the legacy class component state property and setState method which was already a bad API.

class Example extends React.Component {
   constructor(props) {
     super(props);

     this.state = {
       active: false,
       loading: true,
       error: null,
       list: [],
       user: null
     };
   }

   someAction = () => {
      this.setState({
        ...this.state, 
        active: true, 
        loading: false
      })
   }

   render() {
      return (
        ...
      );
    }
}

React went from suggesting a grouped update to a single state update knowing that react performance is bad and that every state update is a component re-render (at least re-render calculation).

React already bathes state updates but this only works when inside React event handler. When we have asynchronous stuff which is very popular now, we are better off grouping state updates.

The previous this.setState was not friendly because it required spreading the current state or passing a callback which would give you access to the state and props that you can use in your state update.

this.setState((state, props) => ({
  ...state,
  active: props.isNew, 
  loading: false
}))

Developers felt the pain when it came to the spreading state. Especially deep-state spreads.

this.setState((state, props) => ({
   ...state,
   list: [
      ...state.list,
      props.item
   ], 
   loading: false,
   user: {
      ...state.user,
      name: "John Doe"
   }
}))

Deeply spreading the state was tough and that’s why lodash was popular and useful back then. It helped with it! Though it was still better than what we have today because it would only do a single state update which is good for your component.

The similar way to use the useState hook would be like this:

const [state, setState] = useState<State>({
   active: false,
   loading: true,
   error: null,
   list: [],
   user: null
});

This is better for your app because you have the option to make grouped updates which will only re-render your component once instead of calling each action from useState . But you still need to spread the state, which is where the pain is.

setState({
   ...state,
   list: [
     ...state.list,
     props.item
   ], 
   loading: false,
   user: {
     ...state.user,
     name: "John Doe"
   }
})

Thankfully, we have useReducer hook that we can use to solve this issue and minimize how many times our components have to re-render.

const [state, setState] = useReducer(
   (prev: State, curr:Partial<State>) => ({...prev, ...curr}), 
   {
     active: false,
     loading: true,
     error: null,
     list: [],
     user: null
});

The above alternative allows us to avoid spreading and still solves group update needs. But it does not handle deep object merging requiring spreading the current state to update it. But just for deep objects.

setState({
   list: [
      ...state.list,
      props.item
   ], 
   loading: false,
   user: {
      ...state.user,
      name: "John Doe"
   }
})

So let’s improve this by using a deep object merge utility function:

const [state, setState] = useReducer(
   (prev: State, curr:Partial<State>) => mergeObjects(prev, curr), 
   {
     active: false,
     loading: true,
     error: null,
     list: []
     user: null
   }
);

Where mergeObjects can be custom or you can use lodash merge utility function:

function mergeObjects(a, b) {
   if(a === null || typeof a !== 'object') return b;
   if(b === null || typeof b !== 'object') return b;

   const obj = Array.isArray(a) ? [...a] : a;

   for(const key in b) {
     if(b.hasOwnProperty(key)) {
       obj[key] = mergeObjects(obj[key], b[key]);
     }
   }

   return obj;
}

We can now abstract all this into a new hook:

const useCompState = <S>(initialState) => {
   const [state, setState] = useReducer(
     (prev: S, curr:Partial<S>) => mergeObjects(prev, curr), 
     initialState);

   return {state, setState}
}

And then use it like this:

const {state, setState} = useCompState<State>({
   active: false,
   loading: true,
   error: null,
   list: [],
   user: null
});

// grouped update
setState({
   list: [
     ...state.list,
     props.item
   ], 
   loading: false,
   user: {
     name: "John Doe"
   }
})

// single update
setState({
   loading: false
});

In the above, I only had to spread the array because it's adding an item to the end, but any deep object value would be automatically handled easily.

Isn't deep-state copy expensive?

It is! This is why it's best to keep the state simple. On the other hand, in modern computers and Javascript engines, the processing power required is next to nothing. Unless you clearly have a performance issue, this should not be an issue.

Take Away

The mutable nature of the state is probably the worse part, unfortunately not one we can do much about without introducing significant API changes. However, we can improve how we interact with state and props data inside our components.

When handling a state like this with a Typescript project, having a State interface to represent the internal data of your component gives you a nice view of what the component deals with in a single place. It’s much better to maintain the component that way.

The grouped update is always better because it reduces the re-renders which helps avoid weird errors and behaviors of components where React batch updates don't work. Not to mention performance improvements.

Let me know what you think in the comments…

YouTube Channel: Before Semicolon
Website: beforesemicolon.com

Better Ways To Handle Data Storage on The Web Client

Elson Correia — Sat, 18 Feb 2023 08:20:57 +0000

Better Ways To Handle Data Storage on The Web Client

Whenever you mention data storage and state management on the web client, different people will provide you with different solutions. From the vanilla developers fans who like to mess with the browser's raw storage APIs to those who prefer third-party libraries, there is a lot to consider when deciding how to handle data on web clients.

Native Browser Storage Solutions

First, let’s look at how browsers allow us to manage, track, and store data from our web applications.

LocalStorage — Part of the Web Storage API, localStorage is a data storage solution for in-between sessions. These are data you want the browser to keep for the next time the user visits the website. Such data have no expiration date but are cleared after a private or incognito session end.
SessionStorage — Also part of the Web Storage API, sessionStorage is a data storage solution for a single session. It works just like localStorage but the data is cleared as soon as the tab for the app is closed.
IndexedDB — A low-level API for client storage. Just like localStorage the data is kept in between sessions but unlike localStorage , it handles a larger, more complex, and structured amount of data. It is also built for performance. Another advantage is that it is accessible inside Web Worker where Web Storage API is not available.
WebSQL — Also a low-level API for client storage intended to work like SQLite but it is currently in the process of being deprecated from browsers.
Cookies — This is not, per se, a data storage solution but it is a way to set a small amount of data often used for tracking, web preferences, and session management (like sessionStorage). Nowadays it is mostly used for tracking as more powerful data storage solutions now exist in the browser.
In-Memory (Javascript)— Increasingly we have seen complex applications keeping all their data in memory. This is more flexible as the developer can decide how the API should look like. This is great for data that only needs to exist between specific contexts but it is often used for global state management as well.

As you can see, the browser pretty much provides a lot of solutions depending on your data needs. However, it is more complex than it seems which leads to a lot of confusion and mental overload for developers.

The problem with Browser Storage Solutions

Serialization: The Web Storage API only supports strings which means that for complex data you must use JSON strings or find a good serialization package to handle everything.
API complexity: If you decide to try IndexedDB or WebSQL you will quickly regret it since the API is super complex. You are much better off using a third-party library if that’s the way want to go.
API differences: All of these data storage solutions are different APIs which means you need to learn them all in order to use them. The problem is, one application may have different data storage needs, and switching back and forward between these APIs adds complexity to your application as they behave differently.
Data type support: Not every data type of your application can be stored. Again, you need to concern yourself with serialization and data type when picking solutions.
Asynchronous actions: IndexDB is asynchronous while Web Storage API is not. Being asynchronous is super important so data processing does not block your code.
Storage Limits and Data size: Although it is getting better, different browsers handle storage limits differently. It also depends on the disk space of the user. As a developer, you need to be mindful of this to make sure you dont run into quota issue which will break your app or find flexible solutions to keep data fresh.
Availability: As mentioned above, only IndexedDB is available in Web Worker which means you may need to find ways around this if you need another type of storage solution. In general, all these storage solutions are well-supported in all browsers.
Structure and Validation: Normally you want your data to have some structure otherwise you will spend a lot of time performing validation checks and data mapping. You may also need to handle defaults which is additional complexity. You may look for some sort of schema to guarantee data integrity so you have to worry about these things less.

A lot of these problems can be solved quickly, others (like limits) you just need to be mindful of as a web developer. Let’s look at few of my preferred solutions.

Third-party library solutions recommendations

If Dealing with IndexedDB and WebSQL

Dexie: this is a wrapper around IndexedDB which removes the complexity and pairs up fine with all your UI Frameworks.


    const db = new Dexie('MyDatabase');

    // Declare tables, IDs and indexes
    db.version(1).stores({
     friends: '++id, name, age'
    });

    // Find some old friends
    const oldFriends = await db.friends
     .where('age').above(75)
     .toArray();

     // or make a new one
     await db.friends.add({
      name: 'Camilla',
      age: 25,
      street: 'East 13:th Street',
      picture: await getBlob('camilla.png')
     });

PouchDB: this is a wrapper around IndexedDB and WebSQL which is compatible with your backend CouchDB setup.

    const db = new PouchDB('dbname');

    db.put({
      _id: 'dave@gmail.com',
      name: 'David',
      age: 69
    });

    db.changes().on('change', function() {
      console.log('Ch-Ch-Changes');
    });

    db.replicate.to('http://example.com/mydb');

JSStore: this is a wrapper around IndexedDB but has a SQL-like behavior.

    const dbName ='JsStore_Demo';

    const connection = new JsStore.Connection(new Worker('jsstore.worker.js'));

    var tblProduct = {
        name: 'Product',
        columns: {
            // Here "Id" is name of column 
            id:{ primaryKey: true, autoIncrement: true },
            itemName:  { notNull: true, dataType: "string" },
            price:  { notNull: true, dataType: "number" },
            quantity : { notNull: true, dataType: "number" }
        }
    };

    const database = {
        name: dbName,
        tables: [tblProduct]
    }

    await connection.initDb(database);

    const insertCount = await connection.insert({
        into: 'Product',
        values: [{
          itemName: 'Blue Jeans',
          price: 2000,
          quantity: 1000
        }]
    });

Handles all Storage Solutions, simple to use, and provides additional features

LocalForage: this is a wrapper around IndexedDB, WebSQL, LocalStorage, and SessionStorage with a way to define more interfaces (called drivers) *for additional storage solutions. It does a great job handling all your serialization needs, it is **asynchronous **and handles a large set of data types. Its **API resembles Web Storage API* and it is ridiculously simple to learn.

    const todoStore = localforage.createInstance({
      name: "todo",
      version: 1,
    });

    const todoId = crypto.randomUUID();
    const todo1 = await todoStore.setItem(todoId, {
      id: todoId,
      name: "Check LocalForage out",
      description: "Try to find the perfect storage solution for my app"
    });

    todoStore.removeItem(todoId)

ClientWebStorage: this is a wrapper on LocalForage — which means it inherits all its benefits —, but takes to a whole new level your data storage needs to also be your preferred application state manager. It is asynchronous, event-driven, schema-based, handles data defaults and type checks for you, allows for data action subscription and interception to handle side effects, and integrates nicely with the backend server for continuous data synchronization. It also can be used as a state management solution for any UI framework like React and Angular.


    interface ToDo {
        name: string;
        description: string;
        complete: boolean;
    }

    const todoStore = new ClientStore<ToDo>("todo", { 
      // define schema
      $name: String,
      description: "No Description",
      complete: false
    }, {
      // config
      type: INDEXEDDB, // LOCALSTORAGE | WEBSQL | MEMORYSTORAGE (default)
      version: 1
    });

    // listen to action events on the store
    todoStore.on(EventType.Error, ({error, action, data}) => {
      trackErrorJS.track(error); // track errors

      console.log(`Action "${action}" failed with error "${error.message}" for data`, data);
    })

    todoStore.intercept(EventType.Created, ({data}) => {
      // intercept create action to call API
      // and return API response to update todoStore with
      return todoService.createTodo(data);
    })

    todoStore.intercept(EventType.Removed, ({id}) => {
      // intercept delete action to call API for same action
      todoService.deleteTodo(id);
    })

    const todo1 = await todoStore.createItem({
      name: "Check ClientWebStorage out"
    });
    /*  Creates
    {
      _id: "123e4567-e89b-12d3-a456-426614174000",
      _createdDate: "January, 4th 2022",
      _lastUpdatedDate: "January, 4th 2022",
      name: "Check ClientWebStorage out",
      description: "No Description",
      complete: false,
    }
    */

    await todoStore.removeItem(todo1._id);

If you are looking for a single full data storage and application state management solution, I recommend taking a look at* ClientWebStorage*. If you just need a data storage solution for everything, LocalForage is the one.

If you are just looking for a solution for your IndexedDB needs I find Dexie to be one of the best but depending on other needs, the others in the list are also good to consider.

Conclusion

The web client is a great platform and as the complexity of web applications increases, a solution for our data storage and management follows. This is a very sensitive topic that needs careful consideration.

You must understand your data well to decide which solutions to go for. There are no silver bullets here but in general, I love swiss knife solutions like ClientWebStorage and LocalForage which offer everything out of the box in a very simple and powerful API that still allows me to configure and extend as needed.

YouTube Channel: Before Semicolon
Website: beforesemicolon.com

How to Setup a TypeScript + NodeJs Server (2023)

Elson Correia — Sat, 18 Feb 2023 07:31:28 +0000

With new releases and tools, setting up a node server has become super simple and until NodeJs ships with typescript built-in, adding typescript is an essential need.

I will show you the SIMPLEST setup you can have to kick off your next node project confidently. For simplicity, you can customize it with the things you need to complete your project.

Project Directory Setup

Let's start by setting you your project directory

mkdir YOUR_PROJECT_NAME
cd YOUR_PROJECT_NAME

git init # start your git project

npm init -y # initialize npm with defaults

mkdir src # create the source directory for all the code

Setting up Typescript

Let's start with a couple of installs…

npm install -D typescript @types/node

The @types/node pretty much sets up types for the entire Node itself.
We can now create the ts-config.json file by running:

npx tsc --init

This will add a ts-config.json file to the root of the project with all defaults including commented-out ones. We need to have the following configurations

{
  "compilerOptions": {
     "target": "es2016",
     "module": "commonjs",
     "rootDir": "./",
     "resolveJsonModule": true, /* in case you are importing JSON files */
     "outDir": "./build",
     "esModuleInterop": true,
     "forceConsistentCasingInFileNames": true,
     "strict": true,
     "noImplicitAny": true,
     "skipLibCheck": true,
  }
}

Feel free to uncomment a few other options to fit your project. This should be good to start.

Create a simple server

To test if everything is working fine, let's add a simple server code.
Create a file src/index.ts and add the following code:

// src/index.ts

import http from "http";

export const server = http.createServer((req, res) => {
  res.writeHead(200, { "Content-Type": "application/json" });
  res.end(
    JSON.stringify({
      data: "It Works!",
    })
  );
});

server.listen(3000, () => {
  console.log("Server running on http://localhost:3000/");
});

This is a simple HTTP Node server listening on port 3000. It should be enough to test our setup.

Now let's try to build this by adding a build script to our package.json file.

"scripts": {
  "build": "tsc"
}

Now if you run npm run build you should see a build directory added to the project root folder with a src directory and the package.json file. The server code should look something like so:

"use strict";
var __importDefault = (this && this.__importDefault) || function (mod) {
    return (mod && mod.__esModule) ? mod : { "default": mod };
};
Object.defineProperty(exports, "__esModule", { value: true });
exports.server = void 0;
const http_1 = __importDefault(require("http"));
exports.server = http_1.default.createServer((req, res) => {
    res.writeHead(200, { "Content-Type": "application/json" });
    res.end(JSON.stringify({
        data: "It Works!",
    }));
});
exports.server.listen(3000, () => {
    console.log("Server running on http://localhost:3000/");
});

This confirms our build works!

Set up how to run the server

We have to think about it in terms of the final build. Because we know the final build will be in the build directory and it will be in javascript, we can set the start script like so:

"scripts": {
  "build": "tsc",
  "start": "node src"
}

The start will not work if we try to run it from our root directory because our source code is in typescript. For that, we need to do a couple more setups.

npm install -D nodemon rimraf npm-run-all ts-node

With those installed let's improve our build by adding a clean script and make the build script clean before the new build.

"scripts": {
  "clean": "rimraf ./build",
  "build": "npm run clean && tsc",
  "start": "node src",
}

With that, let's add the scripts to run the project locally:

"scripts": {
  "clean": "rimraf ./build",
  "build": "npm run clean && tsc",
  "start": "node src",
  "local": "ts-node src",
  "local:watch": "nodemon src -e ts,json --exec 'npm run local'",
}

The local script uses ts-node to run our project instead of node command. This is pretty much a node but in typescript.
But local command only runs the server once and will not detect your changes. That's why the local:watch is needed so we can run the server and watch for changes when you are working.

It uses nodemon to run the project in src directory watching for extensions (-e) ts and json so whenever there are changes to execute ( --exec ) the npm run local script command.

When developing, simply run npm run local:watch .

Note: I am using a JSON Viewer extension in Chrome

Test Setup

I do not recommend going without a test. There have been great things happening on the testing side of things with the release of a built-in test runner in Node which will make things simpler.

However, I still use jest and the following setup is easy to swap to something else if you prefer.

Start with the following installs:

npm i -D supertest @types/supertest jest @types/jest ts-jest

We will be using supertest to test our server and the rest is just jest , its types ( @types/jest) and a jest typescript version ( ts-jest ) to run things.

Now you can add the jest.config.js file to the project root folder with the following code:

module.exports = {
  transform: {
    '^.+\\.ts?$': 'ts-jest',
  },
  testEnvironment: 'node',
  testRegex: './src/.*\\.(test|spec)?\\.(js|ts)$',
  moduleFileExtensions: ['ts', 'js', 'json'],
  roots: ['<rootDir>/src'],
};

The setup is super simple, feel free to add more extensions as you need but overall, that's all you need to start with jest and typescript.
With that, we can add the test script:

"scripts": {
  "clean": "rimraf ./build",
  "build": "npm run clean && tsc",
  "start": "node src",
  "local": "ts-node src",
  "local:watch": "nodemon src -e ts,json --exec 'npm run local'",
  "test": "jest"
}

Now let's test our server by adding the index.test.ts file inside the src directory with the following code:

import supertest from "supertest";
import { server } from "./index";

describe("Server", function () {
  const request = supertest.agent(server);

  afterAll((done) => {
    server.close(done);
  });

  it("should get /", async () => {
    const res = await request.get("/");

    expect(res.status).toBe(200)
    expect(res.body).toEqual({"data": "It Works!"})
  });
});

This is simply checking if when we make a GET request to our basic server, we get what we set it to return.

One thing we need to do now is to exclude test files ( *.test.ts) from our build by adding them to the exclude option in the ts-config.json file.

{
  "compilerOptions": {
     "target": "es2016",
     "module": "commonjs",
     "rootDir": "./",
     "resolveJsonModule": true, /* in case you are importing JSON files */
     "outDir": "./build",
     "esModuleInterop": true,
     "forceConsistentCasingInFileNames": true,
     "strict": true,
     "noImplicitAny": true,
     "skipLibCheck": true,
  },
  "include": [
     "src",
     "package.json"
  ],
  "exclude": [
     "src/**/*.test.ts"
  ]
}

We also want to include the package.json so the npm start can work when we deploy the build directory somewhere like Netlify, AWS ElasticBeanStalk, Heroku, etc.

Use the exclude and include list to add or remove final production artifacts.

ESLint and Prettier Setup

Linting and auto-formatting our code makes it consistent and easier to read. It also catches things we often don't pay attention to by improving the quality of our code even more.

Start by installing few things:

npm install -D @typescript-eslint/parser @typescript-eslint/eslint-plugin eslint prettier eslint-config-prettier

Now create the .eslintrc file with the following code:

{
  "extends": [
    "eslint:recommended", "plugin:@typescript-eslint/recommended", "prettier"
  ],
  "parser": "@typescript-eslint/parser",
  "plugins": [
    "@typescript-eslint"
  ],
  "root": true
}

We can now create the lint , format and format:check scripts like so:

"scripts": {
  "clean": "rimraf ./build",
  "build": "npm-run-all lint format clean && tsc",
  "start": "node src",
  "local": "ts-node src",
  "local:watch": "nodemon src -e ts,json --exec 'npm run local'",
  "lint": "eslint src",
  "format": "npx prettier --write src",
  "format:check": "npx prettier --check src",
  "test": "jest"
}

Note that the build script was changed to run the lint script before the cleaning and build.

You should configure your IDE or code editor to use the eslint configuration to auto-check and format things when you make code saves to get the best of this setup. Otherwise, manually run these commands on your own.

This is how it looks for JetBrains IDEs like IntelliJ and WebStorm:

Final touches

We need the .gitignore file to make sure we don't commit things we don't have to. It should look like this

# IntelliJ project files
.idea
*.iml
out
gen

# VSCode
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json
!.vscode/*.code-snippets

# Local History for Visual Studio Code
.history/

# Built Visual Studio Code Extensions
*.vsix

# Folders
dist
build
node_modules

Take Away

This setup is all you need to start. Depending on your project you may need additional things.

Check all the code in the following template repo. Let me know if you have any questions or need further assistance with something else.

YouTube Channel: Before Semicolon
Website: beforesemicolon.com