DEV Community: Franciszek Krasnowski

Simple KV storage on top of indexedDB

Franciszek Krasnowski — Thu, 30 May 2024 16:25:53 +0000

If your client-side application ever needs to persist a larger portion of data, it's no longer suitable to put it inside a localStorage entry. The first thing that comes into mind is to use indexedDB. But then you have to manage transactions, versioning, etc.

Sometimes all you need may be a straightforward key-value store, that hides those intricacies inside, like:

const kv = await openKV("kv");

await kv.set(key, value);

const data = await kv.get(key);

What is stopping you from building one?
Let's get to work!

Opening up

Working with indexedDB API is not especially pleasant. It's taken straight from the primal age of JavaScript. If you're looking for a more civilized API to digest - check out idb - it enhances the indexedDB API with promises and shortcuts for common operations

But in this post, we're not afraid of the tears and pain of the past

Opening up (the database)

First, we need to open a new connection request. Then attach handlers for success and error events. Everything is enclosed within a compact Promise:

const STORE_NAME = "store";
const openKVDatabase = (dbName: string) =>
  new Promise<IDBDatabase>((resolve, reject) => {
    const request = indexedDB.open(dbName);

    request.onsuccess = () => {
      resolve(request.result);
    };
    request.onerror = () => {
      reject("indexedDB request error");
    };
    request.onupgradeneeded = () => {
      request.result.createObjectStore(STORE_NAME, { keyPath: "key" });
    };
  });

upgradeneeded event will be fired once the database is created (or when its version gets updated). Inside this handler, we can create our one and only store - the KV store. I've put STORE_NAME in a constant as we'll need to use it in multiple places later on

First blood methods

Let's scaffold a basic shape for get, set, and delete methods. They will correspond to indexDB objectStore operations consequently: get, put, and delete

export async function openKV<T = unknown>(dbName: string) {
  const db = await openKVDatabase(dbName);

  const openStore = () => {
    return db.transaction(STORE_NAME, "readwrite").objectStore(STORE_NAME);
  };

  return {
    async get(key: string) {},

    async set(key: string, value: T) {},

    async delete(key: string) {},
  };
}

openStore helper function opens up a new transaction and returns the handle for our KV store

Requests as promised

One more thing needs to be done before implementing the methods. objectStore methods return IDBRequest object. This object achieves the same goal as a promise (it's like a goofy version of it). Let's create a utility that will map them into promises - so we can await them:

function idbRequestToPromise<T>(request: IDBRequest<T>) {
  return new Promise<T>((resolve, reject) => {
    request.onsuccess = () => resolve(request.result);
    request.onerror = () => reject(request.error);
  });
}

Methods

  async get(key: string): Promise<T | undefined> {
      const pair: Pair | undefined = await idbRequestToPromise(
        openStore().get(key)
      );

      return pair?.value as T | undefined;
    },

    async set(key: string, value: T) {
      const pair: Pair = { key, value };
      await idbRequestToPromise(openStore().put(pair));
    },

    delete(key: string) {
      return idbRequestToPromise(openStore().delete(key));
    },

The Pair type used here is just:

type Pair<T = unknown> = { key: string; value: T };

You got to pump it up

As you probably noticed opening a new transaction every time we perform a single key value operation is suboptimal. Consider this snippet:

for (const item of arr) {
    kv.set(item.id, item);
}

To handle an array of 1000 items, we need to open 1000 transactions. If the operations are executed in a single task (triggered synchronously) as in the example above, grouping them into a single transaction (aka batching) could improve efficiency. Let's verify if this assumption holds true

Batching

To implement batching, we need to update the openStore function a little bit

const db = await openKVDatabase(dbName);
// Create 'store' variable to share it between calls
let store: IDBObjectStore | null;

const openStore = () => {
  if (!store) {
    store = db.transaction(STORE_NAME, "readwrite").objectStore(STORE_NAME);

    queueMicrotask(() => {
      // Finish the transaction after the current task ends
      store?.transaction?.commit();
      store = null;
    });
  }

  return store;
};

queueMicrotask allows running code after the current task has been executed (microtasks are run between regular tasks). Learn more here.

Testing

I used tinybench to prepare a basic test case like so:

Promise.all(arr.map((v) => kv.set(v, v)));

Where arr is a 1000-element array of strings

Results

Unsurprisingly there is a small improvement over the 1000 transaction version:

| 1000 transactions | batching     |
| ----------------- | ------------ |
| 7 (ops/sec)       | 32 (ops/sec) |

Transactions

Okay, so when I run queries synchronously, they will be put into a single transaction. But what about the original reason for inventing database transactions? It was to group queries together into one to ensure consistency. Check out this code:

async function inc() {
    await kv.set("x", (await kv.get("x")) + 1);
}

It would only make sense if both set and get operations would form a single transaction

Async / await tracking

Unfortunately, APIs like AsyncLocalStorage that are available in server runtimes including Node.js, Deno, and Bun, that would allow us to track async context are not (yet) available in the browsers. However, we can hook into async / await by leveraging custom Thenables and microtasks scheduling...

If you are interested in learning more about tracking asynchronous contexts, you can check out proposal-async-context - the official ECMAScript proposal that addresses this particular issue

...and then

Userland Thenables can be awaited just like Promises. The key difference if it comes to Thenables is that “then” method is always executed when used in async / await code. This allows us to intercept the async execution of the code and inject hooks before and after the continuation of the async / await block. Here's my attempt at doing that:

export class Thenable<T> {

  constructor(
    private promise: Promise<T>,
    private hooks?: {
      before?: () => void;
      after?: () => void;
    }
  ) {}

  then<U>(onFulfilled: (value: T) => U): Thenable<U> {
    return new Thenable(
      this.promise.then((value) => {
        this.hooks?.before?.();
        const result = onFulfilled(value);
        queueMicrotask(() => this.hooks?.after?.());
        return result;
      }),
      this.hooks
    );
  }
}

Notice how after hook is pushed into the microtask queue. It's because calling onFulfilled will push continuation to the queue itself - this way after hook is called after the continuation microtask

Sharing current transaction

Taking up before and after hooks, we can now make the current transaction accessible from within adjacent queries. Here's the type of the transaction object that will be shared:

type Transaction = {
  store: IDBObjectStore;
  committed?: boolean;
  lastQueried?: boolean;
};

commited and lastQueried flags will be used to implement auto-committing of the transaction. All queries will now be wrapped in a query function to handle sharing.

  const query = <R>(
    fn: (transaction: Transaction<T>) => Promise<R>
  ): Thenable<R> => {
    const transaction = (currentTransaction ??= {
      store: db.transaction(STORE_NAME, "readwrite").objectStore(STORE_NAME),
    });

    // Clear current transaction after current task
    queueMicrotask(() => {
      currentTransaction = null;
    });

    const result = fn(transaction);

    return new Thenable(result, {
      before() {
        // Resume transaction before the continuation
        currentTransaction = transaction;
      },
      after() {
        currentTransaction = null;
      },

    });

  };

And the example of usage:

    set(key: string, value: T) {
      // Wrap handler with query
      return query(async ({ store }) => {
        const pair = { key, value };
        await idbRequestToPromise(store.put(pair));
      });

    },

Auto-commiting

After the series of queries, it would be great to handle commiting automatically. The lastQueried flag will indicate if the queries were executed last microtasks:

  const query = <R>(
    fn: (transaction: Transaction<T>) => Promise<R>
  ): Thenable<R> => {
    const transaction: Transaction<T> = (currentTransaction ??= {
      store: db.transaction(STORE_NAME, "readwrite").objectStore(STORE_NAME),
    });


    // Running `query` will reset the flag
    transaction.lastQueried = true;

    queueMicrotask(() => {
      currentTransaction = null;
    });

    const result = fn(transaction);

    return new Thenable(result, {

      before() {
        currentTransaction = transaction;
        transaction.lastQueried = false;
      },

      after() {
        // If there were no new queries during the last microtask
        if (!transaction.lastQueried && !transaction.committed) {
          transaction.store.transaction.commit();
          transaction.committed = true;
        }
        currentTransaction = null;
      },
    });
  };

Admiring the results

Look at that and think:

async function inc() {
    await kv.set("x", (await kv.get("x")) + 1);
}

The function above now forms a single ACID transaction!

Summing Up

The indexedDB is not the easiest API to work with. It's not the fastest horse in the stable either. It's probably a good idea to use some of the popular wrapper libraries like idb or Dexie.js. That will simplify and streamline the process of working with it. There is also idbkeyval - super-simple key-value store (but without automatic batching and transactions 🙊). Still, implementing your own wrapper may be great fun and will definitely help you understand better how it works

EsNext features in TypeScript with Babel

Franciszek Krasnowski — Thu, 26 Aug 2021 15:11:00 +0000

TypeScript is a statically typed language built on top of JavaScript. It works basically like a type layer for JS - it does not introduce new features to the JS language besides types itself and implementing few syntax proposals. But what if we could extend it further? Would you like to add some custom syntax to the TypeScript? I do. Babel already allows us to spice up JavaScript with syntax plugins. Let's try to do the same with TypeScript

Let's do some tests

After reading this post or cloning this repo and setting our Babel/TypeScript environment I'll install @babel/plugin-proposal-pipeline-operator plugin:

npm i --save-dev @babel/plugin-proposal-pipeline-operator

and add it to .babelrc:

{
  "presets": ["@babel/env", "@babel/preset-typescript"],
  "plugins": [
    "@babel/proposal-class-properties",
    "@babel/proposal-object-rest-spread",
    // add this plugin:
    ["@babel/plugin-proposal-pipeline-operator", { "proposal": "minimal" }]
  ]
}

And we are ready to write some TypeScript code with our fresh pipeline operator:

const triple = (str: string): string => str + str + str;
const kebabify = (str: string): string => str.split('').join('-');
const addQuotes = (str: string): string => `"${str}"`;

export const makeDelicous = (str: string): string => str |> triple |> kebabify |> addQuotes;

The compilation with Babel goes successfully 🥳; however, TypeScript got a couple of errors:

src/index.ts:5:59 - error TS1109: Expression expected.
...

The holy moly

So what? Cannot we use the syntax plugin along with type checking goodness and emitting declaration files?...

Begin again

The key to solving this issue is to change the approach. Instead of compiling source files with Babel down to the desired ES version. We'll use syntax-only plugins:

npm i --save-dev @babel/plugin-syntax-class-properties @babel/plugin-syntax-object-rest-spread @babel/plugin-syntax-typescript

Those plugins do not compile the syntax. They just parse it.

Add the following command to scripts in .package.json:

"build:babel": "babel ./src --out-dir lib --extensions \".ts,.tsx\"",

and type in terminal:

npm run build:babel

After this struggle, output lib/index.js looks like this:

const triple = (str: string): string => str + str + str
const kebabify = (str: string): string => str.split('').join('-')
const addQuotes = (str: string): string => `"${str}"`

export const makeDelicous = (str: string): string => {
  var _ref, _ref2, _str

  return (
    (_ref = ((_ref2 = ((_str = str), triple(_str))), kebabify(_ref2))),
    addQuotes(_ref)
  )
}

Yes, it's perfectly valid TypeScript!

As of the time of writing this post TypeScript compiler does not support compilation of .js files so we'll need a little hack

Little hack

To allow TypeScript to do what it meant to. We need to change the extension of our output files from .js to .ts. So we'll write a simple Node script:

const fs = require('fs')
const path = require('path')

// An argument passed when calling script
const dir = process.argv[2]
if (!dir) throw Error('No directory specified!')
const dirPath = path.join('./', dir)

fs.readdir(dirPath, (err, files) => {
  if (err) throw err
  files.forEach(file => rename(path.join(dirPath, file)))
})

const rename = file => {
  // Matches filenames ending with '.js'
  if (file.match(/.*\.js$/))
    fs.rename(file, `${file.slice(0, -2)}ts`, err => {
      if (err) throw err
      console.log(`Renamed ${file}`)
    })
}

Save it as rename.js then run:

node rename lib

You should see file extension of /lib/index.js changed to .ts

Time for TypeScript to rock!

Change your tsconfing.json to match this:

{
  "compilerOptions": {
    "target": "es5",
    "lib": ["ESNext"],
    // Search under node_modules for non-relative imports.
    "moduleResolution": "node",
    // Enable strictest settings like strictNullChecks & noImplicitAny.
    "strict": true,
    // Disallow features that require cross-file information for emit.
    "esModuleInterop": true,
    // Specify output directory to /dist
    "outDir": "dist",
    "declaration": true
  },
  // Process files from /lib
  "include": ["lib"]
}

Run

tsc

TypeScript processed file successfully!

Linting

You can use ESlint to lint ts files. Install eslint, babel-eslint and @babel/eslint-plugin:

npm i --save-dev eslint babel-eslint @babel/eslint-plugin

Create a simple .eslintrc file in the project root directory:

{
  "parser": "babel-eslint"
}

Additionaly you can install @typescript-eslint/eslint-plugin for TypeScript specifc rules:

npm i --save-dev @typescript-eslint/eslint-plugin

And update .eslintrc:

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

Putting it all together

Make sure to have script for everything in package.json:

"scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "lint": "eslint --ext .ts,.js src/",
    "build:babel": "babel ./src --out-dir lib --extensions \".ts,.tsx\"",
    "build:ts": "tsc",
    "build": "npm run lint & npm run build:babel && node rename lib && npm run build:ts"
  },

Editor support

That's clear that editor support for such a quirk is poor out of the box. If you're using VSCode and wanna get rid of typescript errors; create .vscode directory on the top of your project and put settings.json file in with the following content:

{
  // This makes ts files are recognized as javascript ones:
  "files.associations": {
    "*.ts": "javascript"
  },
  "javascript.validate.enable": false
}

Use ESlint plugin To highlight linting errors. For formatting, I use Prettier plugin. Prettier needs a little configuration to work properly in this circumstance. That is the .prettierrc file:

{
  "overrides": [
    {
      "files": "*.ts",
      "options": {
        "parser": "babel"
      }
    }
  ]
}

Now Prettier will know how to parse our insane ts files. Time to enjoy:

Caveats and sum up

I don't find it really useful; therefore, there's such a strange, almost exotic feeling about this. It's like breaking some laws in exchange for little dirty pleasure. The type-check errors ain't pretty neat, cause they show us code snippets pre-compiled with Babel for example:

lib/index.ts:10:3 - error TS2322: Type 'string' is not assignable to type 'number'.

10   return _ref = (_ref2 = (_str = str, triple(_str)), kebabify(_ref2)), addQuotes(_ref);

but that's only for non-typescript syntax.

What other features do you miss in JavaScript/TypeScript?

Immer vs Ramda - two approaches towards writing Redux reducers

Franciszek Krasnowski — Sat, 20 Feb 2021 15:13:55 +0000

Reducers - a core element of Redux's philosophy that tightly grabs mutations of a given state in one place. In theory, the pure nature of reducers should lead to great scalability, readability, and make us all fortunate children of Redux god. But even the brightest idea can be dimmed if thrown on the one most pediculous soil...

Yes. I speak about JavaScript. Writing complex pure functions in vanilla JavaScript is harsh. Avoiding mutations is extraordinarily hard. Matching against actions? There are no Variants/Enums in JS, you have to use strings instead. And you land with a poor switch statement taken straight from the hell. Regardless, Redux is the most popular state manager for React applications

The path to purity

Consider the two ways to make your life easier, the first one will be the Immer - Immer is a package that lets you deliver the next state by "mutating" the draft of the previous state:

import produce from 'immer'

const replace = produce((draft, key, element) => {
  draft[key] = element
})

const list = ['⚾', '🏀', '🏉']
const newList = replace(list, 1, '⚽')

The replace function is pure, despite the explicitly written assignment of property. It does not change the original object. So with little help of the produce function, you can write mutating logic inside your reducer.

The second way is to use the Ramda library. Ramda is a set of utility functions that perform basic operations on data and functions. And all of them are pure!

import { update } from 'ramda'

const list = ['⚾', '🏀', '🏉']
const newList = update(1, '⚽', list)

The Immer Way

Let's get to work and write a simple "todo" reducer with Immer:

Warning drastic content!

const todosRedcuer = produce((state, action) => {
  const isTodo = todo => todo.id === action.todo?.id
  const remove = (index, arr) => arr.splice(index, 1)

  switch (action.type) {
    case 'ADD_TODO':
      state.unshift({ ...action.todo, id: generateID() })
      break
    case 'CHECK_TODO':
      for (const index in state) {
        if (isTodo(state[index])) {
          state[index].done = !state[index].done
          break
        }
      }
      break
    case 'REMOVE_TODO':
      for (const index in state) {
        if (isTodo(state[index])) {
          remove(index, state)
          break
        }
      }
      break
    case 'EDIT_TODO':
      for (const index in state) {
        if (isTodo(state[index])) {
          state[index].text = action.next.text
          break
        }
      }
      break
    default:
  }
})

It's disgusting. There are so much code and so little meaning in this example. It's under-engineered. Our code does not have to be so procedural. Let's refactor it to be consumable:

const todosRedcuer = produce((state, action) => {
  const isTodo = todo => todo.id === action.todo?.id
  const not = fn => v => !fn(v)
  const todoIndex = state.findIndex(isTodo)

  switch (action.type) {
    case 'ADD_TODO':
      state.unshift({ ...action.todo, id: generateID() })
      break
    case 'CHECK_TODO':
      state[todoIndex].done = !state[todoIndex].done
      break
    case 'REMOVE_TODO':
      return state.filter(not(isTodo))
    case 'EDIT_TODO':
      state[todoIndex].text = action.next.text
      break
    default:
  }
})

Much better. Now you can see the benefits of Immer. We can freely use well-known methods like push pop splice, we can explicitly assign new values. And If it's in your need, you can return from produce and it will behave as a regular function (See the REMOVE_TODO action).

@markerikson - the maintainer of Redux. Advised me that if you consider using Immer to write Redux reducers you should go with Redux ToolKit - the official way to reduce (😎) Redux boilerplate

The die has been cast - Ramda way

Let's recreate the same functionality, this time utilizing the power of Ramda:

const reducer = pipe(uncurryN(2), flip)

const todosRedcuer = reducer(action => {
  const lensTodo = pipe(indexOf(action.todo), lensIndex)
  const lensTodoProp = (prop, state) => compose(lensTodo(state), lensProp(prop))

  switch (action.type) {
    case 'ADD_TODO':
      return prepend({ ...action.todo, id: generateID() })
    case 'CHECK_TODO':
      return state => over(lensTodoProp('done', state), v => !v, state)
    case 'REMOVE_TODO':
      return without([action.todo])
    case 'EDIT_TODO':
      return state => set(lensTodoProp('text', state), action.next.text, state)
    default:
      return identity
  }
})

If you wonder - it's not even worth reading. This code is complex and stupid at the same time - it's over-engineered. When I had written this I've realized I've got too far. Let's refactor it:

const reducer = pipe(uncurryN(2), flip)

const todosRedcuer = reducer(action => {
  const findTodo = indexOf(action.todo)
  const evolveTodo = ev => state => adjust(findTodo(state), evolve(ev), state)

  switch (action.type) {
    case 'ADD_TODO':
      return prepend({ ...action.todo, id: generateID() })
    case 'CHECK_TODO':
      return evolveTodo({ done: v => !v })
    case 'REMOVE_TODO':
      return without([action.todo])
    case 'EDIT_TODO':
      return evolveTodo({ text: () => action.next.text })
    default:
      return identity
  }
})

Ramda functions

Let’s walk through each of these functions:

Before it's too late. All Ramda functions are curried in the sense that we can partially apply arguments to them. So instead:

const add5 = n => add(5, n)

We can do:

const add5 = add(5) // If add is curried

`pipe`

It allows you to compose functions such as the product of the first function becomes an argument of the second one and so on. It reduces the noise when composing functions. And this:

pipe(uncurryN(2), flip)

Is equivalent to this:

fn => flip(uncurryN(2, fn))

Besides, there is compose function in Ramda set. It works exactly the same but in reverse order:

compose(flip, uncurryN(2))

`uncurryN`

It transforms curried arguments of function to standard one. So:

const curriedPower = a => b => a ** b

const power = uncurryN(2, curriedAdd)
power(3, 2) // Returns: 9

Why? I want to use the curried function like action => state => next_state. But Redux expects the reducer to be (state, action) => next_state

`flip`

It swaps the first two arguments of the given function:

const flipPower = flip(power)

flipPower(3, 2) // Returns: 8

Why? If you didn't notice, reducer arguments are reversed. We have (action, state) => ... and flip it to (state, action) => ...

`indexOf`

Works similarly to Array.proptotype.indexOf with the difference that it matches objects too:

indexOf('🐟', ['🦍', '🐖', '🐟'])

You could use findIndex to achieve the same effect. It's Array.prototype.findIndex exposed as curried function:

const isFish = animal => animal === '🐟'

findIndex(isFish, ['🦍', '🐖', '🐟'])

It's the same as:

;['🦍', '🐖', '🐟'].findIndex(isFish)

`equals`

It's how indexOf and other Ramdas functions compare arguments

This function compares two values:

const isFish = equals('🐟')

It's a deep comparison so you can compare objects as well:

equals([1, 2], [1, 2]) // Returns: true

`adjust`

Adjust applies the function to a specific element of the array

adjust(1, n => n * 2, [1, 2, 3]) // Returns: [1, 4, 3]

Why? It's how we aim at specific todo to change it further

`evolve`

One of my favorite functions. It takes the object reducers and applies them for corresponding properties:

const player = {
  level: 4,
  gold: 1858,
  mana: 3000,
}

evolve(
  {
    mana: m => m + 2,
    gold: g => g + 1,
  },
  player
) // Returns: { level: 4, gold: 1859, mana: 3002 }

`prepend`

Works as Array.prototype.unshift but returns a new array instead of modifying the existing one

`without`

It takes the list of elements and array and returns a new array without them. It uses equals to compare elements so you can exclude objects too.

without(['👞', '👢'], ['👞', '👟', '🥿', '👠', '👢']) // Returns: ['👟', '🥿', '👠']

`identity`

It's just:

v => () => v

Why? By default we want to return the previous state without any change

Conclusion

Both Immer and Ramda are great tools to keep purity in js. The big benefit of Immer over Ramda is the fact that you don't have to learn anything new - just use all your JavaScript knowledge. What is more, changes inside produce are very clear. Ramda gives you the right functions to do the job, as a result, your code becomes less repetitive, clean, and very scalable. Of course, you can write all of those functions by yourself, but what is the point of reinventing the wheel? What is the reason to use patterns? If there is a pattern, then there is a place for automation. Nevertheless, these packages can be easily abused. While your code can be too procedural the wrong abstraction may be just as big overhead.

As some others have noticed this "comparison" is not very accurate, since Ramda and Immer are not strict competitors. You'll never stand before the choice "Which one to use over another". It was apparent to me - this form I've chosen is supposed to make the article more entertaining. I don't pressure you to make any choice

Global vs Local State in React

Franciszek Krasnowski — Fri, 25 Sep 2020 18:38:16 +0000

The state and state management is seemingly the most common and interesting topic when it comes to app development on the front-end. Thus everyone is chasing the most efficient and prominent way to manage their application state... are we?

I'm not a guru of the state management world, however; I want to familiarize you with some basic concepts with examples, which are:

State
Global state
Local state (Better put everything in the store 😎)

And further, I'll say:

When to use global and local state?
Popular misconceptions about state management

The State

Why we need the state at all? The state is the current data that our app stores to control its behavior. For example, the checkbox stores data (boolean) if it's on or off.

Global State

Global means our state is accessible by every element/component of the app. But the important fact is that it pollutes the whole app since it echoes in every component that accesses it

Release the beast!

To illustrate the problem lets create a simple counter with React and Redux:



import React from 'react'
import { useDispatch, useSelector } from 'react-redux'
import { inc } from './actions'

export const Counter = () => {
  const dispatch = useDispatch()
  const count = useSelector(store => store.counter.count)

  return (
    <>
      <h1>The count is: {count}</h1>
      <button onClick={() => dispatch(inc())}>Increment</button>
    </>
  )
}

What if I'll do something like this somewhere in the app:



<>
  <Counter />
  <Counter />
</>

You're right. Both counters are showing up the same count:

With useSelector hook we are accessing some data stored in the global store previously declared in our app. So the store probably looks like this:



{
  counter: {
    count: 0
  }
}

It is clear that both counters display the same number cause they reflect the same state

The wind of change

To store multiple counts in the global store. We'll need to do something like this:

Change the structure of the store:



{
  counters: [{ count: 0 }, { count: 0 }]
}

Change the Counter:



export const Counter = ({ part = 0 }) => {
  const dispatch = useDispatch()
  // Now it selects just one of counters
  const count = useSelector(store => store.counters[part].count)

  return (
    <>
      <h1>The count is: {count}</h1>
      {/*We'll also need to change our action factory and reducer */}
      <button onClick={() => dispatch(inc(part))}>Increment</button>
    </>
  )
}

And finally:



<>
  <Counter />
  <Counter part={1} />
</>

Nailed it! Just change store, reducer, component, and manually pass the part property to Counter...
What can go wrong?

Choose your weapon wisely

I am a big fan of MobX. The MobX team did a great job bending JavaScript to allow you to feel reactive in it:



import React from 'react'
import { observable } from 'mobx'
import { observer } from 'mobx-react'

const counter = observable({ count: 0 })

const Counter = observer(() => (
  <>
    <h1>The count is: {counter.count}</h1>
    <button onClick={() => counter.count++}>increment</button>
  </>
))

Wow, it looks so neat!
And with multiple counters:



const counter = observable({ count: 0 })
const counter2 = observable({ count: 0 })

// counter is now a prop:
const Counter = observer(({ counter }) => (
  <>
    <h1>The count is: {counter.count}</h1>
    <button onClick={() => counter.count++}>increment</button>
  </>
))



<>
  <Counter counter={counter} />
  <Counter counter={counter2} />
</>

We end up with less code, but still, we have to pass state manually for each of component 🤦‍♀️

The local state

Even if the above examples seem stupid, the problem is real and it shows why we need a local state. Local state is not the state we define locally. It has the goal to encapsulate the dataflow within the component:



const Counter = () => {
  const [count, setCount] = useState(0)
  const incrememt = () => setCount(count => count + 1)

  return (
    <>
      <h1>The count is: {count}</h1>
      <button onClick={increment}>increment</button>
    </>
  )
}

And voila! counters do not share the state anymore!



<>
  <Counter />
  <Counter />
</>

The dark nature of the local state

Sadly; the local state seems to be much less manageable and debuggable. What's more, it can also hurt the performance of React app if not managed well. When you pass state many levels down and change state somewhere on the top component, all of its children get rerendered (inside virtual DOM) with it. It also tangles components together and makes them less scalable. Redux isolates state from components lifecycle and I/O. On the other hand, stateful components seem to be more modular - statefulness paradox? No. If your app gets more complex things start to be more connected and it's harder to separate them, whenever it comes to global or local state

Local vs global state

The question you should ask yourself to keep state local or global is not to share or not, it's about to encapsulate or not

Which solution to choose

Well established managers like Redux and MobX that supports tools like time-travel (see mobx-state-tree) make debugging a pleasure. But it comes with a cost - Redux is known for being verbose and you have to keep discipline when working with it. It's meant to be used in huge projects. If you insist to use Redux in your tiny app. Take a glance at redux-toolkit - an official tool to reduce Redux boilerplate or search for the other Redux wrapper. Immer is a wonderful library to write reducers. I like Hookstate - a straightforward way to lift the state up. Effector is worth checking and there are plenty of libraries waiting for you to discover them

Don't follow the example

What I'm trying to say is you shoudn't write your code to look exactly like examples in the web. If they want to show how things work they probably sacrifice some good things to be more specific. Reach for Redux Counter from this article and write some custom hook:



const useCounter = (part = 0) => {
  const dispatch = useDispatch()
  const count = useSelector(store => store.counters[part].count)
  const increment = () => dispatch({ type: 'increment' })
  return [count, increment]
}

And our Counter becomes:



export const Counter = ({ part = 0 }) => {
  const [count, increment] = useCounter(part)
  return (
    <>
      <h1>The count is: {count}</h1>
      <button onClick={increment}>Increment</button>
    </>
  )
}

This way we moved most of the state logic outside the component. Hooks are like functions for components. So split your component into hooks and compose them ass (I hope) you do with your functions

Popular misconceptions

Redux is a bad tool because it's too verbose

Redux is crude - that is correct. It is not designed to seduce you with code examples, but to provide transparent data flow

Context API can replace Redux (or any other state manager)

Context API is not a state manager itself. Actually, you have to do all the management yourself like a pagan if you'll use it for that purpose. As if that were not enough, unlike several state managers, it does not optimize re-rendering. Instead, it can easily lead to unnecessary re-renders. Reach for this great article

You can avoid re-renders caused by Context API if you destructure the context value

No! Please, before even thinking of doing that. Read this post written by the Redux maintainer @markerikson

Context API is made for passing _state down (or lifting up)

The truth is: Context API is just a prop passing solution. I think the source of this popular misconception is that a variety of libraries use context for similar purposes, for example: passing theme state. But the theme is something that changes occasionally, and theme change typically should rerender the whole app

MobX users practice voodoo

🙊

Conclusion

I have to confess that this section is troublesome. Should I address some advice? I've read a lot of articles touching this matter and I feel like it's so much to say - it's a complex problem to solve. So I'll just ask: what do you think about the current state of state management in React? and what is your current solution to deal with this problem?

Range in JavaScript using es6 metaprogramming features

Franciszek Krasnowski — Tue, 11 Aug 2020 17:51:52 +0000

Ranges and range like constructs are common features in programming languages. Such as Python:

for x in range(1, 4):
  print(x)
  #prints: 1, 2, 3

Or Scala:

(1 to 4).foreach { print } //prints: 1234

Even Kotlin:

for (i in 1..4) print(i) //prints: 1234

Not to mention functional languages

JavaScript doesn't have an elegant native one range solution, neither for creating arrays nor for iteration only purposes, however; We'll try to cover those issues up and get close to perfection by using es6 Symbol and Proxy

What do you desire?

There are a few things I want to catch up:

Creating array from range
Iterating through range efficiently
Checking if the number is in the given range
Checking if array from range includes a specifying number
Do it all in both ways:
- Using methods like .forEach
- Using for(...) loops and in operator

The easy peasy

Let's create a skeleton for range function:

const range = (start, end, step = 1) => {}

Our range should have a few methods: .forEach, .map, .includes and .has

The difference between .includes and .has is that range(1, 5).has(3) will check if 3 is between 1 and 5, and (1, 5).includes(3) will check if array from given range, which is [1, 2, 3, 4, 5] includes 3 similarly to Array.proptotype.includes

const range = (start, end, step = 1) => {
  // Helper functions:
  const forLoop = fn => {
    for (let x = start; x <= end; x += step) fn(x)
  }
  const between = (v, start, end) => v >= start && v <= end
  const hasValue = v => between(v, start, end) || between(v, end, start)
  // Functions we want to expose:
  const forEach = forLoop
  const includes = v => {
    for (let x = start; x <= end; x += step) {
      if (v === x) return true
    }
    return false
  }
  const has = hasValue
}

Something is missing...

Yeah it's a map function. First create iterate generator:

const iterate = function* (mapFn) {
  for (let x = start; x <= end; x += step) yield mapFn ? mapFn(x) : x
}

Then use spread operator to put it outputs into array:

const map = mapFn => [...iterate(mapFn)]

Create a factory

Adding props with Object.defineProperies seems to be apropriate way:

const rangeObj = {}

Object.defineProperties(rangeObj, {
  map,
  forEach,
  includes,
  has,
})

We should also wrap our methods with { value: method } object to make it work:

// The wrapper function
const createProp = v => ({ value: v })
// Wrap all the methods
const map = createProp(mapFn => [...iterate(mapFn)])
const forEach = createProp(forLoop)
const includes = createProp(v => {
  for (let x = start; x <= end; x += step) {
    if (v === x) return true
  }
  return false
})
const has = createProp(hasValue)

All the code together:

const range = (start, end, step = 1) => {
  const forLoop = fn => {
    for (let x = start; x <= end; x += step) fn(x)
  }

  const between = (v, start, end) => v >= start && v <= end
  const hasValue = v => between(v, start, end) || between(v, end, start)

  const iterate = function* (mapFn) {
    for (let x = start; x <= end; x += step) yield mapFn ? mapFn(x) : x
  }

  const rangeObj = {}

  const createProp = v => ({ value: v })
  const map = createProp(mapFn => [...iterate(mapFn)])
  const forEach = createProp(forLoop)
  const includes = createProp(v => {
    for (let x = start; x <= end; x += step) {
      if (v === x) return true
    }
    return false
  })
  const has = createProp(hasValue)

  Object.defineProperties(rangeObj, {
    map,
    forEach,
    includes,
    has,
  })
  return rangeObj
}

Admire the result:

range(1, 2).forEach(console.log) // Logs: 1, 2
range(2, 5, 2).map(v => v * 10) // Outputs: [20, 40]
...

The meta part

for .. range

That's easy to accomplish. We can attach a custom iterator function to our objects, by utilizing one of the es6 features - Symbols. There are pretty interesting, but we will focus on one of the built-in Symbols - Symbol.iterator. When we set the Symbol.iterator we are replacing its behavior while calling for loops and spread operator:

rangeObj[Symbol.iterator] = iterate

This simple one-liner captures the point. Now if you call our range in for .. of loop, the iterate generator will be executed:

for (let x of range(5, 7)) console.log(x) // Logs: 5, 6, 7

And with spread we can simply create an array from the given range:

;[...range(10, 30, 10)] // Outputs: [10, 20, 30]

`in` operator

To check if the value is in the given range with in operator. Wa cannot use Symbol no more. ES6 introduces another tool - Proxy. Proxy is used to trap calls like set and get to the supplied object. This way you can also trap hasProp which corresponds to in operator calls. That's how it looks like:

const rangeProxy = new Proxy(rangeObj, {
  has(t, p) {
    return hasValue(parseFloat(p.toString(), 10))
  },
})

The t is a target - our rangeObj and the p is a Symbol with the value we want to verify if it's in range. To get the number value of Symbol we need to first call it's .toString method and then parse it with parseFloat. The output of the has function is the output of in expression:

3.8 in range(1, 3) // Outputs: false

A tiny problem

After implementing Proxy you should mark, that when you try to iterate over range it stuck on an Error:

;[...range(2, 5, 2)]
/// TypeError: Invalid attempt to spread non-iterable instance

That's because when we call spread operator it terminates if the object has its iterator and since:

Symbol.iterator in range(1, 3) // Outputs: false

It assumes the object is non-iterable
To fix this, just type:

const rangeProxy = new Proxy(rangeObj, {
  has(t, p) {
    if (p === Symbol.iterator) return true // add this line
    return hasValue(parseFloat(p.toString(), 10))
  },
})

And that's it, we made it. What's left is to give it finishing touch, like making decreasing range - which I previously omitted for sake of simplicity:

const range = (start, end, step = 1) => {
  if (step <= 0) throw RangeError('Step property must be positive')
  if (start > end) step = -step

  const forLoop = fn => {
    if (step > 0) for (let x = start; x <= end; x += step) fn(x)
    else for (let x = start; x >= end; x += step) fn(x)
  }

  const between = (v, start, end) => v >= start && v <= end
  const hasValue = v => between(v, start, end) || between(v, end, start)

  const iterate = function* (mapFn) {
    if (step > 0)
      for (let x = start; x <= end; x += step) yield mapFn ? mapFn(x) : x
    else for (let x = start; x >= end; x += step) yield mapFn ? mapFn(x) : x
  }

  const rangeObj = {}

  const createProp = v => ({ value: v })
  const map = createProp(mapFn => [...iterate(mapFn)])
  const forEach = createProp(forLoop)
  const includes = createProp(v => {
    for (let x = start; x <= end; x += step) {
      if (v === x) return true
    }
    return false
  })
  const has = createProp(hasValue)

  Object.defineProperties(rangeObj, {
    map,
    forEach,
    includes,
    has,
  })

  rangeObj[Symbol.iterator] = iterate

  const rangeProxy = new Proxy(rangeObj, {
    has(t, p) {
      if (p === Symbol.iterator) return true
      return hasValue(parseFloat(p.toString(), 10))
    },
  })

  return rangeProxy
}

Caveats

You should know that es6 Proxy and Symbol aren't poly-filled with tools like Babel, although Proxy::has is covered by 93.12% browsers (by usage) and Symbol.iterator with 93.38%. The range is a simple example of how powerful and flexible your next library can be

DEV Community: Franciszek Krasnowski

Simple KV storage on top of indexedDB

Opening up

Opening up (the database)

First blood methods

Requests as promised

Methods

You got to pump it up

Batching

Testing

Results

Transactions

Async / await tracking

...and then

Sharing current transaction

Auto-commiting

Admiring the results

Summing Up

EsNext features in TypeScript with Babel

Let's do some tests

The holy moly

Begin again

Little hack

Time for TypeScript to rock!

Linting

Putting it all together

Editor support

Caveats and sum up

Immer vs Ramda - two approaches towards writing Redux reducers

The path to purity

The Immer Way

The die has been cast - Ramda way

Ramda functions

pipe

uncurryN

flip

indexOf

equals

adjust

evolve

prepend

without

identity

Conclusion

Global vs Local State in React

The State

Global State

Release the beast!

The wind of change

Choose your weapon wisely

The local state

The dark nature of the local state

Local vs global state

Which solution to choose

Don't follow the example

Popular misconceptions

Conclusion

Range in JavaScript using es6 metaprogramming features

What do you desire?

The easy peasy

Create a factory

The meta part

for .. range

in operator

A tiny problem

Caveats

`pipe`

`uncurryN`

`flip`

`indexOf`

`equals`

`adjust`

`evolve`

`prepend`

`without`

`identity`

`in` operator