Introduction

I have been developing several react hooks libraries. They provide custom hooks for certain purposes. One of them is for web workers. I started it for fun. I got some feedbacks and improved. This post shows the current implementation which aims the use in production.

In this field, Comlink provides a nice transparent API with Proxies. Some might have already tried it with React. I have two reasons why I don’t use it for my library.

Introduction

React context and useContext are very handy. You would have no problem using it while developing a small app. If the size of your app became non-trivial, you might experience some performance issues with regard to useContext. This is because useContext will trigger rerender whenever the context value is changed. This happens even if the part of the value is not used in render. This is by design. If useContext were to conditionally trigger rerenders, the hook would become non-composable.

Motivation

I love Redux. But that doesn’t mean I like all parts of Redux ecosystem. Some people dislike Redux because of its boilerplate code. That’s sad. Boilerplate code is not from the Redux core, but from the ecosystem. Don’t get me wrong. Best practices are nice and I think the recent work of Redux Starter Kit is great. (Claps to Mark)

I think I have my own understanding of how to use Redux with React. It may not be common and probably it will never be the mainstream. I understand Redux is useful and tuned for larger applications. What I have in mind is the usage for smaller apps and for beginners.

Introduction

I have been developing several React hooks libraries for months. In this post, I will explain why and how I developed a React Redux binding library with React hooks. The library is implemented to be concurrent mode friendly. Let’s discuss why it’s important and what’s the technique behind it.

React concurrent mode has not come yet, and all discussions are based on the current unstable behavior. Please note that when concurrent mode is released and best practice is researched, things may change.

Introduction

React useContext is very handy to avoid prop drilling. It can be used to define global state or shared state that multiple components in the tree can access.

However, useContext is not specifically designed for global state and there’s a caveat. Any change to context value propagates all useContext to re-render components.

This post shows some example code about the problem and the solution with state usage tracking.

Problem

Let’s assume a person object as a state.

Introduction

React hooks have changed the way to compose components. This post will show an example which is very hooks-oriented.

We use two libraries: react-tracked and immer. While immer makes it easy to update state in an immutable way, react-tracked makes it easy to read state with tracking for optimization. Please check out the repo for more details.

https://github.com/dai-shi/react-tracked

The example we show is the one from Redux: Todo List

Folder structure

- src/
  - index.tsx
  - state.ts
  - hooks/
    - useAddTodo.ts
    - useToggleTodo.ts
    - useVisibilityFilter.ts
    - useVisibleTodos.ts
  - components/
    - AddTodo.tsx
    - App.tsx
    - FilterLink.tsx
    - Footer.tsx
    - Todo.tsx
    - VisibleTodoList.tsx

We have two folders components and hooks. Components are basically views. Hooks include logic.

Introduction

There are many libraries for global state with React hooks. React Redux also provides hooks API, which is very clean.

In general, I would avoid using global state. It would reduce the isolation of components. Multiple contexts should work fine for certain use cases.

But, what if we really need a global state.

Problem

When a state is a non-trivial object, it’s not likely to use all properties of the object for one component to render.
 What most libraries do is to provide a selector interface. With the selector interface, developers can specify which part of the state to use in a component. In general, a selector is a function, but there are alternative ways to specify part of the state. For example, by property names or paths. In any case, developers are responsible to write proper selectors.


Introduction

Since React hooks landed, there has been many libraries proposed for global state. Some of them are simple wrappers around context. Whereas, some of them are full featured state management systems.

Technically, there are several implementations how to store state and notify changes. We don’t go in detail in this post, but just note two axes.

1. whether context based or external store
2. whether subscriptions based or context propagation

In this post, we focus on API design of hooks at the consumer end. In my observation, there are four approaches to the API design. Let’s see each approach by example in pseudo code. As a simple example, we assume an app that has the followings.

Introduction

useReducer is a powerful hook. It’s known that useState is implemented with useReducer.

In the React hooks docs, it’s noted like this:

useReducer is usually preferable to useState when you have complex state logic that involves multiple sub-values or when the next state depends on the previous one. useReducer also lets you optimize performance for components that trigger deep updates because you can pass dispatch down instead of callbacks.

For a long time, I misunderstood that useReducer is more powerful than useState and there’s some optimization that can’t be achieved by useState.

Introduction

React-Redux provides hooks API with nice abstraction. Especially, useSelector is probaly less misused than mapStateToProps.

react-tracked is a library for global state without Redux. This library provides almost compatible hooks API to React-Redux. It’s developed with performance in mind, and it should be as performant as React-Redux, even though it utilizes only React context. See the GitHub repo for more information.

https://github.com/dai-shi/react-tracked

This post shows benchmark results to convince that it actually is performant in one scenario.