State as a Snapshot in React

Run this and predict what the counter shows after one click.

function Counter() {
  const [count, setCount] = useState(0);

  function handleClick() {
    setCount(count + 1);
    setCount(count + 1);
    setCount(count + 1);
  }

  return <button onClick={handleClick}>{count}</button>;
}

It shows 1, not 3. The three lines are not redundant and they are not being collapsed by an optimization. Each one reads count, finds 0, and asks React to render again with 1. Three identical requests, one result.

The reason is that state is a snapshot: for the whole life of one render, the state variable holds a single fixed value, and nothing that happens during that render can change it. The setter does not assign to the variable — it schedules the next render, and the new value only exists there.

That single idea explains three things that otherwise look unrelated: why repeated updates collapse, why logging state right after setting it shows the old value, and why awaiting inside a handler does not help.

The order ticket analogy

Picture a kitchen. A customer orders, and a ticket is printed and handed to the cook. The cook works from the ticket in their hand — not from the customer, who is out of sight in the dining room.

A render is one printed ticket. Everything that runs during that render — the component body, the event handlers it creates — reads the ticket, never the kitchen's current situation.

Two details make the analogy accurate:

• The ticket cannot be edited. Calling the setter is telling the front of house to print a new one, and the cook keeps holding the old one until it arrives.
• Three notes saying "add one to the number on this ticket" all produce the same number, because they all read the same printed value.

And one detail where it breaks:

A cook can walk out and look at the dining room. A handler cannot. There is no call that returns the current state from inside the render that is holding an older copy — the only way to see the new value is to be running in the render that has it.

What actually happens

   render #1                          render #2
  ┌────────────────────────┐         ┌────────────────────────┐
  │ count = 0              │         │ count = 1              │
  │                        │         │                        │
  │ handleClick reads  ────┼──► 0    │ handleClick reads  ────┼──► 1
  └────────────────────────┘         └────────────────────────┘
             │                                  ▲
             │  setCount(0 + 1) three times     │
             └───── all three schedule 1 ───────┘

count is declared with const. That is not a stylistic choice — it is the literal truth about the value. Each render is a fresh call to the component function, producing a fresh const that never changes while that call is on the stack.

So the handler is not reading a stale copy of a variable that has since moved on. It is reading the only value that variable ever had.

The updater form

To escape the snapshot, stop naming the value and describe the change instead.

setCount(c => c + 1);
setCount(c => c + 1);
setCount(c => c + 1);
// 3

React queues the three functions and applies them in order. The first receives 0 and returns 1; the second receives that 1 and returns 2; the third returns 3. None of them ever looks at count.

The two forms answer different questions:

setCount(count + 1); // ❌ "make it one more than the render's value"
setCount(c => c + 1); // ✅ "make it one more than whatever is pending"

Use the updater form whenever the new value depends on the old one. When it does not — setting a field from an input event, resetting to zero — the plain form says what it means and is easier to read.

Several updates, one render

The other half of the surprise is that React does not re-render between the calls.

function handleClick() {
  setCount(c => c + 1);
  setName('Ada');
  setOpen(true);
  // one render, not three
}

React collects the updates queued during an event and processes them together. This is batching, and it is why the handler runs to completion before anything re-renders — which in turn is why the snapshot stays fixed for the whole handler.

Batching is a feature, not a limitation. Without it, the component would render in intermediate states where count had changed but name had not.

The trap: reading state after an await

This is where the snapshot catches people who have already understood the rest.

async function handleSave() {
  setSaving(true);
  await api.save(draft);
  console.log(saving); // ❌ still false
}

Awaiting suspends the function and resumes it later — but it resumes inside the same render, holding the same ticket. saving was false when this handler was created and it is false on every line of it, forever.

The fix is not to await differently. It is to stop asking:

async function handleSave() {
  setSaving(true);
  await api.save(draft);
  setSaving(false); // ✅ tell React what to do, do not read back
}

The same mechanism makes a callback in setInterval see one frozen value — the effect that created it belongs to one render. See Closures Explained for why the captured variable behaves that way, and Effect Cleanup in React for what to do about the interval itself.

Where it shows up: the value you send to the server

The bug that costs real time is not a counter. It is sending the wrong data.

function handleSubmit() {
  setQuantity(quantity + 1);
  api.createOrder({ quantity }); // ❌ sends the old quantity
}

The order goes out with the value from before the click, while the screen updates to the new one a moment later. Nothing throws, the UI looks right, and the mismatch only surfaces in the database.

function handleSubmit() {
  const next = quantity + 1; // ✅ compute once
  setQuantity(next);
  api.createOrder({ quantity: next });
}

Compute the value once, into a local variable, then use that local for both the update and everything else in the handler.

Side-by-side

The rule of thumb

Whenever you are about to read a state variable, ask which render you are standing in. If the answer is "the one before the update I just queued", you are reading a snapshot and it will not have changed.

Two moves cover almost every case:

1. Computing the next value? Use the updater form.
2. Need the value again in this handler? Put it in a local variable first, and never re-read the state.

Version and environment notes

• Automatic batching is React 18. From 18 onward, updates batch wherever they happen — promises, setTimeout, native event listeners. Before that, only React event handlers batched, so two updates inside a fetch callback rendered twice.
• Snapshot semantics themselves have not changed. They are the same in React 19, and were the same in class components, where this.setState took an updater function for exactly this reason.
• In development, StrictMode renders each component twice. A console.log in the body appearing twice is StrictMode, not a double update — check a production build before chasing it.
• flushSync from react-dom forces a synchronous re-render and is the documented escape hatch. It is rarely the right answer; reach for it only when you must read the DOM between two updates.

Check yourself

1. What does this print, and what does the button show?

function App() {
  const [n, setN] = useState(0);

  function onClick() {
    setN(n + 1);
    setN(n + 2);
    console.log(n);
  }

  return <button onClick={onClick}>{n}</button>;
}

2. What is on screen after one click?

function App() {
  const [n, setN] = useState(0);

  function onClick() {
    setN(c => c + 1);
    setN(n + 10);
    setN(c => c + 1);
  }

  return <button onClick={onClick}>{n}</button>;
}

Sources

• React — State as a Snapshot
• React — Queueing a Series of State Updates
• React — useState
• React — React 18: Automatic batching