Introduction

In the world of web frontend development, signals have become a popular topic. At their core, signals are used to represent changes in state over time. Some developers have discussed the potential of using signals in conjunction with React.

Signals are actually an older concept, and it’s uncertain how they are understood by modern web developers. Initially, I was confused about the characteristics of signals, but I later realized that they can be boiled down to two main aspects:

Introduction

When I first saw SolidJS and Preact Signals, I thought they are interesting but they are different from React. What made me motivated is @preact/signals-react. I didn’t like the original implementation using REACT INTERNALS, and that drove me to create something.

We already had Jotai. Jotai atoms are like signals, representing reactive sources, and allowing to form a dependency graph or a data flow. The missing piece was signal-like syntax without hooks.

Introduction

When Jotai development was started (before releasing v1), it has a simple goal. It optimizes re-renders, which was often a problem with useState and useContext using a big state object. We also wanted to avoid using selector function, which is popularized by Redux and widely used.

In the early days, I wanted to have data fetching solution, but didn’t want to complicate Jotai itself. So, jotai/query package was created. It’s an integration with React Query v3. It went well, but I noticed a certain mismatch with users. While my mental model was to create a data fetching API for Jotai, people want full features from React Query. I had been struggling with the mismatch, and ended up with creating a new library jotai-tanstack-query. It integrates TanStack Query v4 and covers full features.

Introduction

Jotai is a library for React state management.

The API (let’s call it v1 API) is designed to a) be friendly with Concurrent React, and b) be compatible with Recoil as much as possible.

What does it mean? First, atom read function is evaluated in the render phase in React.

For example, consider a simple derived atom.

const countAtom = atom(0);
const doubleAtom = atom((get) => get(countAtom) * 2);

In the example, (get) => get(countAtom) * 2 is the read function. When countAtom is updated, the library doesn’t invoke the read function of doubleAtom immediately. Instead, it triggers the component that uses doubleAtom to re-render. The component re-renders eventually, and it’s when the read function of doubleAtom is invoked. The benefit of this behavior might be hypothetical, but React allows to schedule re-renders, which means it can skip invoking read functions in concurrent rendering.

Introduction

If someone has already looked into package.json in the jotai library, they may find "exports" field.

https://github.com/pmndrs/jotai/blob/v1.6.4/package.json#L18-L31

  "exports": {
    "./package.json": "./package.json",
    ".": {
      "types": "./index.d.ts",
      "module": "./esm/index.js",
      "import": "./esm/index.mjs",
      "default": "./index.js"
    },
    "./utils": {
      "types": "./utils.d.ts",
      "module": "./esm/utils.js",
      "import": "./esm/utils.mjs",
      "default": "./utils.js"
    },

In the Node.js docs, it is described as Package entry points. Node.js v12.7.0 started implementing it. Nowadays, it’s used also by bundlers like webpack and vite.

We use package entry points for separating modules. For example, jotai is a core module exporting core functions. jotai/utils is a separate module which exports additional functions based on core functions. (By the way, another option is to publish two packages instead. But, we prefer multiple entry points in a single package.)

Introduction

Recently, I often got asked about this question: Which is recommended, valtio or jotai?

For those who are not familiar with them, they are two out of many state management libraries that I developed.

https://github.com/pmndrs/valtio

https://github.com/pmndrs/jotai

Now, from the library perspective, their implementations are very different. However, from the usage perspective, I understand the confusion. Both serve similar functionalities and we don’t usually use both in a single app.

Introduction

In the previous article, we explained how Valtio proxy state works. It tracks mutations of state and create immutable snapshot.

Let’s recap the API in vanilla part of Valtio.

// Create a new proxy state to detect mutations
const state = proxy({ count: 0 });

// You can mutate it
++state.count;

// Create a snapshot
const snap1 = snapshot(state); // ---> { count: 1 }

// Mutate it again
state.count *= 10;

// Create a snapshot again
const snap2 = snapshot(state); // ---> { count: 10 }

// The previous snapshot is not changed
console.log(snap1); // ---> { count: 1 }

// You can subscribe to it
subscribe(state, () => {
  console.log('State changed to', state);
});

// Then, mutate it again
state.text = 'hello'; // ---> "State changed to { count: 10, text: 'hello' }"

Now, let’s see how we can use the state in React.

Introduction

I stumbled upon 7GUIS tasks while reading XState Tutorials. This motivated me to challenge those 7 tasks with jotai.

It turned out that this would be a good resource to learn jotai. They are from basic tasks to advanced tasked, and you will see how they are implemented, occasionally magically.

It’s recommended to try it yourself first. If you succeed to implement it, then you can compare. Even if you fail, you can read and learn.

Introduction

Valtio is a library for global state primarily for React. It’s originally modeled to match with useMutableSource API. However, it turns out it’s a novel API to add immutability to mutable state.

What is immutable state? JavaScript doesn’t support immutability as language, so it’s just a coding contract.

const immutableState1 = { count: 0, text: 'hello' };

// update the state
const immutableState2 = { ...immutableState1, count: immutableState1.count + 1 };

// update it again
const immutableState3 = { ...immutableState2, count: immutableState2.count + 1 };

Some people might be familiar with this pattern, or it can be new to some other people. We always create a new object without modifying the existing ones. This allows us to compare the state objects.

Introduction

The React team announced The Plan for React 18 with various features. Among them, concurrent rendering is one of my interests because I have been developing various global state libraries and there are known issues called “tearing” and “branching”.

Tearing is an undesirable behavior in which two components render with different values for same global state.

Branching is a desirable behavior in which a component renders with a stale value for a state in a transition update.