setState is a request: snapshots, update queues, and automatic batching

State is a snapshot; setState is a request

If you’ve ever called setState twice and seen only one update, the reason is right here. A render works with a frozen copy of state. When React calls your component, useState returns the values as of that render, and every closure created during it — event handlers included — captures those values forever. Calling setPoints does not change points; it cannot, because points is a const in a function call that already finished or is about to. What setPoints(next) actually does is append an update to a queue on the hook’s fiber and schedule a re-render. Only when that next render runs does React reduce the queue and hand your component the new value.

That is the entire mechanism behind the most-asked React interview question. In a handler where count is 0, calling setCount(count + 1) three times enqueues “replace with 1” three times — each line read the same snapshot. The next render reduces the queue: 1, 1, 1. Final value: 1, one render. The mental model “setState is slow/async assignment” is wrong in a way that matters: it is not a delayed write, it is not a write at all. It is a request for a future render computed from whatever you passed in — and what you passed in was computed from a stale-by-design snapshot.

Updater functions: sending instructions instead of values

The queue accepts two kinds of entries: a replacement value, or an updater function. setPoints(p => p - cost) enqueues the function itself; during the next render React reduces the queue in order, feeding each updater the result of the previous entry. That makes a sequence of updaters compositional where replacement values are not:

function Redeem({ cost, bonusCost }) {
  const [points, setPoints] = useState(500);

  function redeemCombo() {
    // Bug: both lines read the same snapshot (points = 500).
    // Queue: [replace 400, replace 450] — the second wins. Result: 450.
    setPoints(points - cost);       // cost = 100
    setPoints(points - bonusCost);  // bonusCost = 50
  }

  function redeemComboFixed() {
    // Queue: [p => p - 100, p => p - 50], reduced in order:
    // 500 -> 400 -> 350. Result: 350, still exactly one render.
    setPoints((p) => p - cost);
    setPoints((p) => p - bonusCost);
  }
}

Mixing forms follows the same reduction: with count at 0, the sequence setCount(c => c + 1), setCount(42), setCount(c => c + 1) reduces 0 → 1 → 42 → 43. The replacement discards everything before it; updaters build on whatever precedes them. The same snapshot logic explains stale closures outside handlers: an interval created on mount captures that first render’s count forever, so setCount(count + 1) inside it pins the value at 1 — setCount(c => c + 1) reads the live queue state instead and counts correctly. The rule that falls out: any update derived from the previous state must use the updater form. It is not a style preference; it is the only form the queue can compose.

Automatic batching: what React 18 actually changed

Batching is React collapsing multiple setState calls into one render and one commit. React 17 batched only inside React event handlers — the synthetic-event call stack it controlled. The moment your code left that stack, batching ended: in a promise .then, a setTimeout, a native addEventListener, each setState triggered its own synchronous render-and-commit pass. Three setStates in a fetch callback meant three full renders back-to-back — and code in the wild silently depended on that, reading the freshly committed DOM between two setState lines.

React 18 with createRoot made batching automatic everywhere: handlers, promises, timeouts, native events — all updates in one tick are queued and flushed in a single render. The performance delta is mechanical: a fetch callback setting loading, data, and pagination state went from 3 render+commit passes to 1 — on a heavy page, the difference between one 40 ms frame and three. The migration failure mode is the inverse: code that relied on the React 17 flush-per-call — measure the DOM after setState in a timeout, or a test asserting intermediate renders — now reads stale DOM, because the commit happens after the whole callback finishes. Updates inside transitions batch separately from urgent updates, but within each lane the rule holds: one flush per batch.

flushSync: the escape hatch and its bill

Sometimes you genuinely need the DOM updated now, mid-handler: append a chat message and scroll the list to it, focus an input that the next render will create, populate state before the browser’s print dialog snapshots the page. flushSync(fn) runs the updates inside fn and synchronously forces render and commit before returning — the next line of your handler sees the committed DOM.

import { flushSync } from "react-dom";

flushSync(() => {
  setMessages((prev) => [...prev, newMessage]);
});
// DOM is committed: the new <li> exists, scroll targets the real node.
listRef.current.lastChild.scrollIntoView({ behavior: "smooth" });

The bill is exactly what batching saved you: each flushSync is a full synchronous render+commit on the main thread, inside your handler. Three flushSync calls re-create React 17’s worst case, except now deliberately. It defeats batching for those updates, blocks the handler until commit finishes, forces layout earlier than the browser would have, and can fire effects synchronously. The senior heuristic: flushSync is for imperative DOM reads that must observe the new state — scroll, focus, measure, print — and nothing else. If you reach for it to “fix” a stale value in your own JavaScript logic, the actual fix is an updater function or deriving the value locally; flushSync there is a 40 ms band-aid over a 4-character bug.