In a React component with `const [count, setCount] = useState(0)`, a click handler calls `setCount(count + 1)` three times in a row, yet each click only raises the count by one. Explain why, and what to write instead.

## The snapshot model is the whole answer Every render of a component is a separate call to the function, and `useState` returns the value React currently holds. That binding is fixed for the whole render, and every closure created during that render — including your `onClick` handler — captures it. So in the render where `count` is 0: ```jsx function handleClick() { setCount(count + 1); // setCount(0 + 1) setCount(count + 1); // setCount(0 + 1) <- count is still 0 setCount(count + 1); // setCount(0 + 1) } ``` Nothing in the handler can change `count`; it is a constant for that render. All three calls compute 1 and ask React to make the state 1. React honours all three, in order, and the result is 1. ## What the updater form changes The setter accepts either a value or a function. When you pass a function, React treats it as an **updater**: instead of "make the state this", it means "make the state whatever comes out of applying this to the state you have when you get here". React applies queued updaters in call order when it computes the next render: ```jsx function handleClick() { setCount(c => c + 1); // c is 0 -> 1 setCount(c => c + 1); // c is 1 -> 2 setCount(c => c + 1); // c is 2 -> 3 } ``` The parameter is not the render's `count`; it is the state as of that point in the applied sequence. That is why the updater is immune to a stale snapshot and the computed value is not. ## The rule to state in an interview **If the next state is derived from the current state, pass a function.** `setCount(c => c + 1)`, `setItems(prev => [...prev, item])`, `setOpen(o => !o)`. If the next state is independent of the old one — `setName(inputValue)`, `setError(null)` — passing the value directly is fine and reads better. This matters far beyond three calls in a row. Any callback that outlives the render that created it holds a stale snapshot: an interval, a debounce, a WebSocket handler, an async continuation after `await`. All of them are correct with an updater and quietly wrong with a computed value: ```jsx useEffect(() => { const id = setInterval(() => setCount(c => c + 1), 1000); return () => clearInterval(id); }, []); // with setCount(count + 1) this would stick at 1 ``` ## Updaters must be pure React may call an updater more than once (in development it deliberately double-invokes to surface impurity). An updater must compute a new value from its argument and do nothing else — no fetching, no logging you count on, no mutating the argument. `setItems(prev => { prev.push(x); return prev; })` is wrong twice over: it mutates and it returns the same reference. ## Batching is a separate fact Candidates often blame batching for the wrong number. Batching is why you get **one render** instead of three, and since React 18 it applies everywhere — event handlers, timeouts, promise callbacks, native handlers — not just in React events. But batching does not change the values you queued: three updaters still yield 3 inside one batched render. Keep the two explanations apart, because an interviewer who hears "batching swallowed two of my updates" knows the model is fuzzy. ## Reading state after setting it `setCount(c => c + 1); console.log(count);` logs the old number, and there is no callback argument to the setter that hands you the new one (that is class-component `setState`, not the hook). If you need the value you just computed, compute it into a local first: ```jsx const next = count + 1; setCount(next); send(next); ``` If the value depends on queued updates you cannot see, do the work in an effect keyed on the state instead. ## The compact answer Say: the handler closed over `count` from its render, so three calls all requested the same value; pass `setCount(c => c + 1)` so each call receives the result of the last; and separately, the three calls always collapse into one render because updates are batched.