How React Batches State Updates

React batches state updates by waiting until your event handler finishes, then applying every change in one re-render. One handler can call several setters and still cause only a single render. This is what keeps the UI fast and consistent.

Why batching exists

Without batching, every set call would trigger a re-render immediately. A handler that updates two values would paint the screen twice, and the user might briefly see a state where only one value has changed and the other is still stale.

Batching removes those half-finished frames. React records all the updates first, then renders once with the final values.

It is like a waiter writing down the whole order before walking to the kitchen. It also saves work, because rendering is often more expensive than the handful of set calls that queue it.

Updates inside one handler

A component with two state variables shows the effect. Clicking the button updates both values, but React renders only once, so the user never sees a frame where items moved and subtotal did not.

App.jsx

import { useState } from "react";
 
function Checkout() {
  const [items, setItems] = useState(0);
  const [subtotal, setSubtotal] = useState(0);
  function handleAdd() {
    setItems(items + 1);
    setSubtotal(subtotal + 10);
  }
  return <button onClick={handleAdd}>Add item: {items} ({subtotal})</button>;
}

Click the button and both numbers move together in one update. The handler calls two setters, React queues both, and the next render shows items at 1 and subtotal at 10 at the same time.

Batching across components

Batching is not limited to one component. When a single event updates state in several components, React applies all of those updates in the same re-render.

This means one click that changes a parent and a child still paints the screen once. The final render reflects every update together, so you never see a tree where only some parts have moved and others lag behind.

Batching and updater functions

Batching changes how you read values during the same event. A plain value reads the snapshot from the start of the handler, so three set calls with the same value still produce one change.

When the next value depends on the previous one, pass an updater function so each call reads the latest queued value. Updaters are the standard way to work inside a batch, because they always see the latest value in the queue.

App.jsx

setItems((previous) => previous + 1);
setItems((previous) => previous + 1);
setItems((previous) => previous + 1);

These three updaters are applied in order during the next render, so the count rises by three. Without an updater, three set calls using the same snapshot each queue the same replacement, so the count moves only once. That is batching and snapshots working together, which is why state feels stale when you log it right after setting it.

A change in React 18

Older versions of React batched updates inside browser events but not inside timers, promises, or async callbacks. React 18 made batching automatic everywhere.

A set call inside a setTimeout or after an await is now batched the same way as one inside an onClick handler. Code written for the old behavior may expect an extra render that no longer happens, but the change only removes unnecessary renders and does not alter the final state.

When batching does not apply

Batching covers updates inside a single event, like one click or one keypress. React does not batch across separate events, so two clicks produce two renders.

In rare cases you need the screen updated before the handler ends, for example to measure the DOM after a change. React exports flushSync for that, but it defeats the performance benefit of batching, so reserve it for that measurement case.

What to learn next

Batching explains most state timing questions. Next, see useState in action if you want the Hook itself, or learn when to combine several values into one state object instead of many hooks.