
import { Callout } from "@craftvalue/blog";

The Children Prop Pattern is the most underused and underappreciated pattern in
React. It's the only pattern that matters. For two reasons

- it improves the readability of component trees ;
- it improves performance.

## So... what is the Children Prop Pattern ?

Look at the code below:

```typescript
function Container() {
  return (
    <div className="container">
      <UserList />
    </div>
  );
}

function UserList() {
  return (
    <div className="user-list">
      <UserItem />
      <UserItem />
      <UserItem />
    </div>
  );
}
```

We can see that the `UserItem` elements do not depend on any local variables
inside the `UserList` component.

It is a perfect candidate for the children prop pattern.

To use the children prop pattern, we rewrite the above code to move the
`UserItem` elements above in the tree and add a `children` prop to the
`UserList` component. It gives us the following:

```typescript
function Container() {
  return (
    <div className="container">
      <UserList>
        <UserItem />
        <UserItem />
        <UserItem />
      </UserList>
    </div>
  );
}

function UserList({ children }: { children: React.ReactNode }) {
  return <div className="user-list">{children}</div>;
}
```

The `children` prop is a special prop in React: React automatically populates
it with the content between the opening and closing tags of the component.

## Composition

The children prop pattern is a form of composition. It allows you to compose
components together. It allows you to build complex components from simpler
ones.

It improves the readability and maintainability of your code. You can avoid props
drilling with this pattern and even prevent using the Context API.

## Can I use this pattern every time?

Short answer, no.

As I said above, this pattern only works when the children's elements do not
depend on their parent component's internal variables.

For instance, we cannot rewrite the following to use this pattern. The
`div` element and the `UserItem` elements depend on the `selected` variable.

```typescript
function UserList() {
  const [selected, setSelected] = React.useState(0);

  return (
    <div
      className={classnames("user-list", {
        "has-selection": selected !== null,
      })}
    >
      <UserItem selected={selected === 0} />
      <UserItem selected={selected === 1} />
      <UserItem selected={selected === 2} />
    </div>
  );
}
```

### Do I need to use the `children` prop name?

The children prop pattern does not limit itself to the `children` prop name.
You could use any name to pass down elements like `kids` or `element`.

The only difference for the `children` prop is that you have the tree syntax
offered by JSX.

For instance, the React Router library uses the `element` prop name to pass
down elements.

```typescript
function App() {
  return (
    <Router>
      <Route path="/users" element={<UserList />} />
    </Router>
  );
}
```

## Performance

Performance-wise, this pattern is exciting...

Let's consider the following code below:

```typescript
function Container() {
  return (
    <div className="container">
      <UserList>
        <UserItem />
        <UserItem />
        <UserItem />
      </UserList>
    </div>
  );
}

function UserList({ children }: { children: React.ReactNode }) {
  const [count, setCount] = React.useState(0);
  return (
    <div className="user-list">
      <button onClick={() => setCount(count + 1)}>Click me</button>
      {children}
    </div>
  );
}
```

Before continuing below, can you answer the following question:

> when the `UserList` element updates due to its state updating, do the
> `UserItem` elements re-render?

I'll let you think about it for a moment.

The answer is no. The `UserItem` elements will not re-render because they are
not part of the `UserList` component tree. They are part of the `Container`
component tree.

When the `UserList` component updates, it uses the prop `children` to render
its content. The `children` prop is stable between `UserList` re-renders due to
`count` state updates. It is the same reference, object, in short elements. So
the React reconciliation algorithm will not re-render the `UserItem` elements.

Yes, you read it right, the `children` prop is not re-rendered
when the component re-renders : the prop `children` comes from outside the component.

Do not believe me ? [Try it in this CodeSandbox](https://codesandbox.io/s/children-prop-pattern-re-render-comparison-6nol2q?file=/src/App.js).

<figure>
  <object
    data="/images/blog/2022/children-prop-pattern-perf-comp.svg"
    type="image/svg+xml"
    width="100%"
    style={{ objectFit: "cover", height: "500px" }}
  />
<figcaption>

If you check the Profiler tab, you will see that the `UserItem` elements are not
re-rendered when the `UserList` component re-renders.

</figcaption>
</figure>

That is why I say that a component re-renders when the parent that
**instantiates** it re-renders. In our case, the parent of the `UserItem`
elements is the `UserList` component, but the parent that instantiates them is
the `Container` component. So the `UserItem` elements will re-render when
the `Container` component re-renders.

Take a moment to think about this in terms of performance.

## Conclusion

With this article, you should now understand how powerful the Children Prop
Pattern is and how it can help you improve your codebase and components.

Did you like this article? Don't hesitate to share it or leave a comment below 🙂.


While it is one of the most underused patterns in React, the Children Prop
Pattern is a powerful tool for building reusable components. But it has
another aspect that makes it even more interesting to understand and use: 
re-renders optimization.


The **Children Prop Pattern** in React


import { Callout } from "@craftvalue/blog";

Doing some workshops on React and seeing some people struggling with React Hooks
on StackOverflow made me realize that some new React developers don't have a
proper understanding of some JavaScript concepts that are crucial to
understand React Hooks. This article summarizes the most important JavaScript
concepts to play a role in React Hooks. Let's name them:

- Primitive vs. Reference values
- Memoization
- Closures
- Immutability (Declarative/Functional vs. Imperative programming)

## **Primitive 🆚 Reference Values**

I think this is the most crucial concept to understand. It wasn't apparent for
me when I started development with, well, JavaScript.

### What is a **Primitive Value?**

A primitive value in JavaScript is a value that is not an object: it has no
method or properties.

Seven data types are primitive in JavaScript: `null`, `undefined`, booleans,
symbols, numbers (including `NaN`), `bigint`, and strings.

### And a **Reference Value?**

A reference value is an object. In other words, everything that is not a
primitive value: objects, arrays, functions, etc.

A reference value references an object in memory.

This is important to know due to the points described below.

### Reference Values and **Comparison**

Reference values imply that each value references an object in memory.

Two reference values may reference the same object in memory. Two reference
values may also reference two different objects that have the same shape and
property values but live at distinct places in memory:

<figure>
<object
  data="/images/blog/2022/reference-values-in-memory.svg"
  type="image/svg+xml"
  width="100%"
  style={{ objectFit: "cover" }}
/>
<figcaption>

On this schema, `userA` and `userB` reference two different objects in memory.
These values are deeply equal but not shallowly equal: they do not reference
the same object in memory.

On the other hand, as `userC` is assigned to `userD`. `userD` now references the
same object as `userC`. `userD` and `userC` are equal shallowly and deeply.

</figcaption>
</figure>

### React uses **Shallow Comparison**

React uses shallow comparison everywhere with
the comparison function [`Object.is`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is):

- in hooks dependency list ;
- by default for `React.memo` props equality ;
- for bailing out state updates.

This is important, and that's why I repeat it, but you really need to
understand the following snippets:

<figure>

```typescript
const userA = { id: 2, name: "John" };
const userB = { id: 2, name: "John" };
console.log(Object.is(userA, userB));
// >> false
// While
const userC = { id: 2, name: "John" };
const userD = userC;
console.log(Object.is(userC, userD));
// >> true
```

<figcaption>

In above snippet, `userA` and `userB` are not shallowly equal: they do not
reference the same object. `userC` and `userD` are shallowly equal: they
reference the same object.

</figcaption>
</figure>

For primitive values, it is "simpler":

<figure>

```typescript
const a = 1;
const b = 1;
console.log(Object.is(a, b));
// >> true

const c = "foo";
const d = "foo";
console.log(Object.is(c, d));
// >> true
```

<figcaption>

Primitive values that have the same values are shallowly equal. Check
[`Object.is`
reference](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is)
for details and comparison with `===`.

</figcaption>
</figure>

<Callout important>

If we sum up, **shallow comparison** will compare **values for primitive values**
and **references for reference values.**

</Callout>

So every time you consider some code in React, ask yourself:

- are the values reference or primitive values?
- if they are reference values, are they new references or stable references?

It will considerably help you understand what is happening. And if you have any
bugs, it will help you solve them.

## **Memoization**

This technique consists of caching the result of a function based on
input parameters. This is useful to avoid recomputing the result of a
function if the input parameters are the same.

Let's take a quick example of what would be a memoized function:

<figure>

```typescript
const square = (n) => n * n;

function memoize(fn) {
  const cache = {};
  return (n) => {
    if (cache[n]) return cache[n];

    const result = fn(n);
    cache[n] = result;
    return result;
  };
}

const memoizedSquare = memoize(square);

console.log(memoizedSquare(2));
// >> 4 // compute and cache
console.log(memoizedSquare(2));
// >> 4 // return cached value
```

<figcaption>

In this example, `memoize` is a helper function that cache the result of
`square` based on the input parameter `n`.

</figcaption>
</figure>

In React, this concept is used to cache function references (`useCallback`) or
function return values (`useMemo`).

### **`useCallback`**

Consider the following component:

```typescript
import React from "react";

export function MyForm() {
  const [showForm, setShowForm] = React.useState(false);
  const focusElement = (ref) => ref?.focus();

  return (
    <>
      <button onClick={() => setShowForm(true)}>Show form</button>
      {showForm && <input type="text" {...inputProps} ref={focusElement} />}
    </>
  );
}
```

We pass the `focusElement` function to the `ref` prop of the `input` element.
A new function is created on each render, assigned to the `focusElement`
variable and passed to the `ref` prop.

This is not a problem if `MyForm` component is not re-rendered. But if it is
re-rendered, React will call the `focusElement` function again. If the value
assigned to the `ref` prop differs from the previous one, React calls this
value again.

To solve this, we use the `useCallback` hook:

```typescript
import React from "react";

export function MyForm() {
  const [showForm, setShowForm] = React.useState(false);
  const focusRef = React.useCallback((ref) => ref?.focus(), []);

  return (
    <>
      <button onClick={() => setShowForm(true)}>Show form</button>
      {showForm && <input type="text" {...inputProps} ref={focusRef} />}
    </>
  );
}
```

The `useCallback` hook returns a memoized version of the function that we pass
as the first argument to the hook. The second argument is the dependency list.
If the dependency list is empty, the function is memoized only once. If the
dependency list is not empty, the function is memoized only if the values of
the dependency list are different from the previous render. This comparison is
made using **shallow comparison.**

### **`useMemo`**

The `useMemo` hook is similar to `useCallback`, but it memoizes the return value
of the function passed as the first argument to the hook.

```typescript
import React from "react";

export function List({ count }: { count: number }) {
  const items = React.useMemo(
    () => new Array(count).fill(0).map((_, i) => i * i),
    [count]
  );

  return (
    <>
      {items.map((value) => (
        <div key={value}>{value}</div>
      ))}
    </>
  );
}
```

In this example, the `items` array is computed and memoized every time the
`count` prop changes. But it is not recomputed if the `count` prop is the same
as the previous one (shallow comparison). The return value **is memoized**.

## **`Closures`**

Before abording the case of `useEffect` hook, I want to talk a bit about
closures.

A closure is a function that remembers its lexical scope, the scope defined at
the function creation time. In other words, a closure is a function that has
access to the outer function's variables, even after the outer function has
returned.

It's like at the function creation, a picture was taken of the references of
the variables outside the closure function.

If you have used React, you have used closures:

```typescript
function MyComponent() {
  const [isShown, setIsShown] = React.useState(false);

  return (
    <>
      <button onClick={() => setIsShown(true)}>Show</button>
      {isShown && <div>Content</div>}
    </>
  );
}
```

The function assigned to the `onClick` property of the `button` element is a
closure. It has access to the `setIsShown` function and the `isShown` variable.

### **Implications**

#### **`useState`**

Let's consider the implication for `useState`:

```typescript
function MyComponent() {
  const [count, setCount] = React.useState(0);

  const onClick = () => setCount(count + 1);

  return (
    <>
      <button onClick={onClick}>Increment</button>
      Count: {count}
    </>
  );
}
```

The `onClick` function is a closure. When the function `onClick` is created, it
"retains" the value of the variable count at this moment. On the first render,
its value is `0`. Each time the component re-render, a new closure function is
created in memory, and its reference is assigned to the `onClick` variable.

If we click the button twice really fast, the resulting `count` variable will
be `1` and not `2`.

**Why?**

The `onClick` function is called on the first click and registers a state update with the new value `1`. But state updates are asynchronous, and React
will re-render the component when it has time. So on the second click, the
`onClick` handler is called again. But this closure has access to the `count`
variable at the time of the closure creation. The `count` variable is still
`0`, and the state is again updated to `1`.

To solve this, we use functional updates:

```typescript
function MyComponent() {
  const [count, setCount] = React.useState(0);

  const onClick = () => setCount((count) => count + 1);

  return (
    <>
      <button onClick={onClick}>Increment</button>
      Count: {count}
    </>
  );
}
```

The closure does not depend on the `count` variable anymore. And React
guarantees that the `count` variable passed to the `setCount` callback is the
latest value of the `count` variable.

#### **`useEffect`**

The `useEffect` hook is a bit more complex. It runs the callback function
after the first render and everytime that the dependency list changes.

Let's check this snippet I analyzed during one of my workshops. The aim was to
log the `id` passed in props when the component becomes visible in the
viewport, and this only once for the same `id` value.

```typescript
function Card() {
  const [wasSent, setWasSent] = React.useState(false);
  const cardRef = React.useRef<HTMLDivElement>(null);

  const options = {
    threshold: 0.9,
  };

  React.useEffect(() => {
    if (!cardRef.current) return;

    const onVisibilityChange = (entries) => {
      if (!entries[0].isIntersecting) return;
      if (wasSent) return;

      setWasSent(true);
      console.log(`Card ${id} is visible`);
    };

    // The IntersectionObserver is a browser API that triggers a callback
    // when elements become visible in the viewport.
    const observer = new IntersectionObserver(onVisibilityChange, options);

    observer.observe(cardRef.current);

    return () => observer.disconnect();
  }, []);

  return <div ref={cardRef}>Card</div>;
}
```

<Callout title="Can you spot what may not work here?" info>

</Callout>

Let's do a summary. We have two nested closures: the `onVisibilityChange` one
and the effect function (the anonymous function).

The effect has an empty dependency list, so it will only run after the first
render.

The `onVisibilityChange` closure has access to the `wasSent` variable and is
created when the effect is run. So here, `wasSent` is always `false`.

To avoid this, we could pass `wasSent` as a dependency to the effect:

```typescript
React.useEffect(() => {
  // ...
}, [wasSent]);
```

But this is not an ideal solution in this case. `wasSent` is neither displayed
nor used to display content, we may prefer a reference:

```typescript
function Card() {
  const wasSentRef = React.useRef(false);
  const cardRef = React.useRef<HTMLDivElement>(null);

  const options = {
    threshold: 0.9,
  };

  React.useEffect(() => {
    if (!cardRef.current) return;

    const onVisibilityChange = (entries) => {
      if (!entries[0].isIntersecting) return;
      if (wasSentRef.current) return;

      wasSentRef.current = true;
      console.log(`Card ${id} is visible`);
    };

    // The IntersectionObserver is a browser API that triggers a callback
    // when elements become visible in the viewport.
    const observer = new IntersectionObserver(onVisibilityChange, options);

    observer.observe(cardRef.current);

    return () => observer.disconnect();
  }, []);

  return <div ref={cardRef}>Card</div>;
}
```

## Some last words: **Imperative, Declarative, Functional Paradigms**

I will briefly sum up the difference between these paradigms (it is a
simplified explanation):

- with **Imperative Programming**, you tell the computer what to do and how to do
  it. You have to write the steps to achieve a result.

- with **Declarative Programming**, you tell the computer what you want but not
  how to do it.

- **Functional Programming** is a subset of declarative programming that
  encourages creating new data instead of mutating existing data.

<Callout danger title="Use functional programming with React">

React uses shallow comparison everywhere. So if you mutate an object, you may
not observe the behavior you expect on your UI.

Always create new data when you want to mutate objects. This also means not
using in-place methods for arrays (like: `.sort`, `.reverse`, `.push`, `.pop`,
`.shift`, `.unshift`, `.splice`, etc.).

</Callout>

Prefer spread operator to create data:

```typescript
const newObject = { ...oldObject, newKey: newValue };

const newArray = [...oldArray, newValue];
```

Consider the following example:

<figure>

```typescript
function List() {
  const [items, setItems] = React.useState([]);

  const addItem = () => {
    const newItems = items;
    newItems.push("new item");
    setItems(newItems);
  };

  return (
    <>
      <button onClick={addItem}>Add item</button>
      <ul>
        {items.map((item) => (
          <li key={item}>{item}</li>
        ))}
      </ul>
    </>
  );
}
```

<figcaption>

This example will not work as expected. The `items` array is mutated in place
by the `addItem` function. So the `items` array passed to `setItems` is the
same reference as the `items` array before the mutation. React will bail out
the state updates and not re-render our component.

</figcaption>
</figure>

If you are skeptical, try this
[CodeSandbox](https://githubbox.com/gpichot/react-sandboxes/tree/main/sandboxes/hooks/usestate-illustrate-bug-with-imperative-side-effects).

## **Conclusion**

I hope you enjoyed this article! I tried to explain many of the JavaScript
concepts necessary to understand hooks in React and how they work. I hope it
gave you a better understanding of how the hooks work in React, as much as
these concepts have helped my workshop attendees 😉.


Hooks are hugely related to more general JavaScript concepts like closures,
memoization, and primitive vs. reference values. Correctly understanding
these concepts and their role in React Hooks is essential to use them
properly.


**Understanding React Hooks:** JavaScript Fundamentals


import { Callout } from "@craftvalue/blog";

`useState` is a :term[hook]{key=react:hook} provided by React to provide state to
:term[functional components]{key=react:functional-component}. It is one of the
most used hooks of React. Its interface is just one line:

```typescript
const [count, setCount] = React.useState(0);
```

The interface consists of :

- an initializer value: `0` here
- an array as return value with:
  - the current state value at the first index: here unpacked to `count`
  - a setter at the second index: here `setCount`

The initializer value will **be used on the first render** to initialize
the state with this value. For re-renders, React will not use the initializer.

The first item of the return value (here `count`) will hold the current state
value.

The second item is a function called the setter. Called with a new value, it
_will_ mutate the state value and trigger a re-render _if needed_.

<Callout note title="Convention">

When destructuring the `useState` return value, always name the setter with
the prefix `set` followed by the variable name in Capital Camel Case
(`MyVariable`).

Example: setter for `usersCount` will be named `setUsersCount`.

</Callout>

Today, we will go a bit further to review everything to know about
the `useState` hook (items followed by ⚛️ have a specific paragraph in the [official
React documentation][1]:

- :term[lazy initial state]{key=react:lazy-initial-state}: using a function as
  initializer value ⚛️
- :term[functional updates]{key=react:functional-updates}: use a function for updating
  ⚛️
- :term[bailing out state updates]{key=react:bailing-out-state-updates}: setter
  triggers a re-render only on strict value change ⚛️
- state values (primitive value, array, object, function)
- typing with TypeScript
- state updates are asynchronous
- stability of the setter and implications
- batched updates (before & after React v18) ⚛️
- state updates and transitions

<Callout question title="Do I need to know all this?">

Well, if you are already familiar with the `useState` hook, you are fine. However,
knowing about all these points will help you understand subtleties and
make you more proficient in debugging codes and performance issues. In
short, it will make you a better React developer.

Also, when I interview for potential hires, I looooveee 😍 to ask this kind
of question: _"What can you tell me about the `useState` hook in React?"_.
Depending on the answer, it will give me a reasonable estimate of how much the
candidate knows about React.

</Callout>

## Basics ⚽

### Lazy initial state ⚛️

In some cases, the initial state of the `useState` hook may take time to
compute. In this case, you can use the `lazy` initial state value version by
using a function that will return the initial state. This function will be
called on the first render and **only on the first render** to initialize the
state.

For instance, consider the following piece of code:

```typescript
/**
 * Create a grid of 1000 rows by 1000 columns
 */
function createInitialGridValues(initialGridValue = 1) {
  const rows = new Array(1000).fill(0);
  return rows.map((_, rowIndex) =>
    new Array(1000)
      .fill(initialGridValue)
      .map((_, columnIndex) => columnIndex * rowIndex)
  );
}

export function Grid({ initialGridValue }: { initialGridValue: number }) {
  const initialGridValues = createInitialGridValues(initialGridValue);
  const [gridValues, setGridValues] = React.useState(initialGridValues);

  // do something with `gridValues`
}
```

`createInitialGridValues` may be compute time intensive (even more if you use a
10k by 10k grid). Therefore we prefer to implement it like this:

```typescript
export function Grid({ initialGridValue }: { initialGridValue: number }) {
  const [gridValues, setGridValues] = React.useState(() =>
    createInitialGridValues(initialGridValue)
  );

  // do something with `gridValues`
}
```

### Functional updates ⚛️

It's a valuable feature to mutate the state if the new state value depends on
the previous. The setter can accept a function that receives the
last state value and return the new state value.

```typescript
export function MyComponent() {
  const [count, setCount] = React.useState(0);

  return (
    <>
      Count: {count}
      <button onClick={() => setCount((prevCount) => prevCount - 1)}>-</button>
      <button onClick={() => setCount((prevCount) => prevCount + 1)}>+</button>
    </>
  );
}
```

<Callout question title="What is it preferred to `setCount(count + 1)`?">

If the user rapidly clicks multiple times on the button, React may not have the
time to re-render your component: on the second click, the count value would
be the "old" value leading to inconsistent behavior and React would bail out
the state updates (see below).

</Callout>

### Bailing out state updates ⚛️

React is smart: if we call the setter with a new value that equals the old
value (shallow comparison), React will not change the state. **No
re-render will be triggered.** **Effects will not be fired.** It avoids
unnecessary re-renders.

<Callout important>

React use
[Object.is](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is#description)
for comparison between old and new state values: it's similar to the strict
equality operator === with some differences.

</Callout>

This last bit is essential to know as it's a mistake that I found from time to
time in the code that I reviewed.
I teach to use functional programming to mutate the state to avoid these bugs:

- Prefer destructuring and spread operators for arrays and
  objects ;
- Never use in-place methods or mutating expressions (like
  `array.push`, `array.splice`, etc.) because non-primitive values are
  **reference values**.

<Callout example>

Consider the following code:

```typescript
type MyItem = { title: string };
export function MyComponent() {
  const [items, setItems] = React.useState<MyItem[]>([]);

  return (
    <>
      {items.map((x) => x.title).join(", ")}
      <button
        onClick={() => {
          items.push({ title: `Title ${items.length}` });
          setItems(items);
        }}
      >
        Add item
      </button>
    </>
  );
}
```

If you click the `Add item` button, no re-render will be triggered: the
`items.push` method mutates the `items` array in place.

The reference to the value stays the same while the value has changed in
memory. It's better to use functional expressions like:

```typescript
setItems(items => {
   const newItem = { title: `Title ${items.length}` };
   setItems(items => [...items, newItem]);
}
```

The same goes for object values and all non-primitive values.

</Callout>

### State values

We can use everything as state value: primitive values (nullish values,
booleans, number, string) and reference values (arrays, objects).

#### Functional expressions

I repeat it but it's crucial: use functional expressions (destructuring,
spread operator, etc.) to update the state.
If you don't create a new reference, React will not trigger a re-render.

#### Function as state value

In some exotic use cases, you may want to store functions as state values. In
this case, do not forget to set the new value using the functional update
version. If you don't, React will call your function will the previous state
value:

```typescript
// Use
setHandler(() => myNewHandler);
// NOT (React will call myNewHandler with the previous value)
setHandler(myNewHandler);
```

## Intermediate 🏅

### Typing `useState` with TypeScript

Most of the time, type inference will do the job: you will not need to type the
state explicitly.

Sometimes, you may need to use generics to type the state explicitly, for
instance, when using null values:
`useState<UserDetails | null>(null)`.

### Setter is asynchronous

The state value is set asynchronously in React when using the setter, which
means that the state is only changed when the component is re-rendered by
React. It's a mechanism that allows the earlier stated **bail out of updates**.

In other words, when you call the setter, the code is not executed
synchronously.
To React to state changes, you must use `React.useEffect`.

### Setter stability

The setter (second element returned by `React.useState`) is stable between
re-renders: the function `setState` (`setCount` in our first example) is a
reference to the same function during all re-renders. It's safe to
omit it from the hooks dependency list (`useEffect`, `useCallback`,
`useMemo`...).

It's why [`react-hooks/exhaustive-deps` eslint
rule](https://github.com/facebook/react/tree/main/packages/eslint-plugin-react-hooks)
lets you omit the setter from deps list.

## Advanced 🏆

### Batched updates ⚛️

React `useState` official doc and the [React v18 upgrade
guide](https://reactjs.org/blog/2022/03/08/react-18-upgrade-guide.html#automatic-batching)
explain this feature.

It's a performance feature: React groups multiple state updates into a single
re-render for better performance.

Before v18, React batches state updates from React event handlers only (for
instance, multiple state updates triggered from the same `onClick` handler).

From v18 and using `createRoot`, React batches all updates. It includes
state updates from timeouts, promises, and native event handlers.

<Callout note>
React keeps things consistent: it only batches state updates from different
user-initiated events.

On the contrary, state updates from the same user-event (for instance, when
clicking a button twice) are treated separately.

You may want to consider this if a state change triggers a network call or some
compute-intensive code.

</Callout>

### React v18 Transitions: urgent vs non-urgent state updates

Starting from v18, React introduces the
concept of :term[Transitions]{key=react:transitions} (see [React v18.0 – React
Blog](https://reactjs.org/blog/2022/03/29/react-v18.html#new-feature-transitions)):
using the
[startTransition](https://reactjs.org/docs/react-api.html#starttransition)
function or the [`React.useTransition`
hook](https://reactjs.org/docs/hooks-reference.html#usetransition), you may
declare some state updates as non-urgent vs. urgent updates like user-triggered
state updates (click on a button, text input, etc.).

You can check this article [Don't Stop Me Now: How to Use React useTransition()
hook](https://dmitripavlutin.com/react-usetransition/) for an example about
it.

## References

- [useState - Hooks API Reference – React](https://reactjs.org/docs/hooks-reference.html#usestate)
- [Automatic batching for fewer renders in React 18](https://github.com/reactwg/react-18/discussions/21)
- [React v18.0 – React Blog](https://reactjs.org/blog/2022/03/29/react-v18.html#new-feature-transitions)
- [Automatic Batching - How to Upgrade to React 18 – React Blog](https://reactjs.org/blog/2022/03/08/react-18-upgrade-guide.html#automatic-batching)


A complete guide to React.useState hook mechanisms.

All you need to know about React.useState

Gabriel Pichot

Gabriel accompagne start-ups et grands groupes sur leurs projets webs et digitaux. Il partage au sein de ses projets son expérience acquise sur des technologies comme ReactJS, TypeScript, AWS ou encore l'agilité.

Ses formations sont le lieu d'échanges et de retours d'expériences, clefs pour vous transmettre, à vous ou à vos équipes les savoirs nécessaires à une utilisation efficace des outils que vous utilisez. C'est son principal objectif : transmettre un savoir-faire pratique, un véritable artisanat issu d'expérience sur de multiples projets, un ensemble de bonnes pratiques qui booste l'impact que le développeur a sur son travail et sur les projets auxquels il contribue.



Gabriel Pichot

Formations proposées

Articles