Loading...
Spaceplay← →stepRreset
See how React batches state updates with an interactive visualization. Watch multiple setState calls queue up, updater functions run in order against the pending value, and one render commit for all of them, including inside timeouts and promises.
Loading visualization...
State batching is how React collects every setState call made during one event handler or callback into a single render, so the UI updates once with the final result instead of once per call.
Calling setState does not change anything immediately. It records an update on the hook's queue and asks React to render later. Batching is the rule for when "later" is: React waits until the current handler or callback finishes, then processes every queued update in one render pass and commits once.
Each render captures its state as a snapshot. The count variable inside an event handler is a plain constant captured by a closure, so three setCount(count + 1) calls in a row all compute the same number. To build on the pending value instead of the snapshot, you pass an updater function, setCount(c => c + 1), and React calls it with the result of the previous queued update.
Before React 18, batching only applied inside React's own event handlers. Updates made in a setTimeout, a promise callback, or a native event listener each rendered synchronously on their own. React 18 introduced automatic batching for roots created with createRoot: updates are batched wherever they come from, with the batch boundary at the end of the callback that issued them.
This design matters because rendering is the expensive part. One render per tick keeps intermediate states off the screen, avoids running effects for values nobody sees, and lets React treat the update queue as data it can reorder by priority under concurrent rendering. flushSync exists as the explicit escape hatch for the rare case where the DOM must be updated before the next line of code runs.
Interview framing: define State Batching in one sentence, then explain one concrete runtime behavior and one common pitfall with a short code example.
Logging count right after setCount prints the old value. The handler's count is a closure over the render that created it, and the render that would produce the new value has not run yet.
Fix: Compute the next value in a local variable and use that, or move logic that depends on the committed state into a useEffect keyed on that state.
Every call reads the same snapshot, so three calls queue three updates with the same payload and the final state increments by one.
Fix: Use the updater form, setCount(c => c + 1), whenever the next state depends on the previous state. React feeds each updater the result of the one before it.
On a React 17 legacy root, or a React 18 app still mounted with ReactDOM.render, each setState inside a setTimeout or .then callback triggers its own synchronous render.
Fix: Mount with createRoot to get automatic batching everywhere. If a component still needs several updates to land together on an older root, wrap them in unstable_batchedUpdates or combine them into one state object.
flushSync forces a synchronous render and commit in the middle of the handler, which defeats batching and can noticeably hurt performance when overused.
Fix: Reserve flushSync for cases where the DOM must be current before the next statement, such as measuring a node or scrolling to a freshly inserted item. Everything else belongs in effects or derived state.
Common interview prompts with concise model answers.
count is a constant captured when the component rendered with value 0. All three calls evaluate count + 1 to 1 and queue three replace-with-1 updates. React processes them in one render and the result is 1.
function handleClick() {
setCount(count + 1); // queues 1
setCount(count + 1); // queues 1
setCount(count + 1); // queues 1
}
// one render, count === 1A value update replaces the state outright when React reaches it in the queue. An updater is stored as a function and called during the render with the pending state at that point, so consecutive updaters chain: 0 to 1 to 2 to 3. Mixing them still runs in call order, so a trailing value overwrites whatever the updaters computed.
setCount(count + 5); // queue: replace with 5 (count was 0)
setCount(c => c + 1); // queue: 5 -> 6
setCount(42); // queue: replace with 42
// one render, count === 42React 17 batched updates only inside React event handlers; updates in timeouts, promises, and native listeners each rendered on their own. React 18 with createRoot batches automatically in every callback, so two setState calls inside a .then produce one render instead of two.
flushSync runs its callback, then synchronously renders and commits any updates it queued before returning, so code after the call can read the updated DOM. It bypasses batching for that update and blocks the main thread for the render, so it should be limited to layout measurement or scroll positioning after a state change.
flushSync(() => {
setItems([...items, newItem]);
});
// DOM already has the new row here
listRef.current.lastChild.scrollIntoView();React does not use a timer to batch. Inside an event handler it holds updates until the handler returns and then flushes synchronously in the same task. For updates issued from a microtask or timer callback, React 18 schedules a flush that runs once that callback finishes, so the batch boundary lines up with a single unit of event loop work.
Continue with these concepts to strengthen your mental model.
function Counter() { const [count, setCount] = useState(0); function handleClick() { setCount(count + 1); setCount(count + 1); setCount(count + 1); console.log(count); } return <button onClick={handleClick}>{count}</button>;}queue empty
waiting
no renders yet
waiting
No output yet.