useState

## The return value is a pair `useState` takes one argument — the initial state — and returns an array with exactly two entries. Array destructuring is the convention because it lets you name both halves whatever you like: ```jsx function Counter() { const [count, setCount] = useState(0); return <button onClick={() => setCount(count + 1)}>{count}</button>; } ``` The first entry is the state value **as of the render that is currently running**. The second is a setter function that asks React to store a new value for this component and schedule a re-render. There is no third element, no object with named fields, and no way to read current state back out of the setter. ## The value is a snapshot, not a live channel The most common mental-model error is imagining `count` as a live view onto a box React owns, so that writing to it writes into the box. It is not. Each time React renders your component it calls the function again, and on each call `useState` returns the value it is currently holding for that component instance. The destructured binding is created fresh on every call and is fixed for the duration of that call — a snapshot. Every closure created during that render (event handlers, effect callbacks, timers) captures that snapshot, which is why handlers see the value from the render that created them rather than the newest one. ## Why the assignment does nothing In an event handler — code that runs after the render has already produced DOM — assigning to the binding cannot change anything on screen, because the JSX for that render was built and committed before the handler ever ran. Two sub-cases: - With the usual `const [count, setCount] = ...`, `count = count + 1` throws a `TypeError`: assignment to a constant. Module and JSX-compiled code is strict-mode code, so this is a hard error, not a silent no-op. - With `let [count, setCount] = ...`, the assignment succeeds and updates a variable that is about to be garbage-collected along with the rest of that render's scope. React never observed it, so no render is scheduled, and on the next render `useState` returns the value React is still holding — your write is gone. The same applies to mutating what state holds: pushing into an array or setting a field on an object changes data React can see, but it still never told React to render. ## The setter is the only channel Calling `setCount(next)` does three things: it records the requested update against this component instance, it marks the component as needing to re-render, and it returns `undefined`. It does not assign to your `count` binding, and it does not run the component synchronously. That is why this logs the old number: ```jsx function handleClick() { setCount(count + 1); console.log(count); // still the value from this render } ``` The binding for the current render is immutable by design; the new value appears in the *next* render's binding. ## Two more properties worth knowing **The setter's identity is stable.** React guarantees the same setter function across renders of the same component, so you can safely omit it from a dependency array or pass it down to a memoized child without causing extra work. **State is per component instance.** Rendering `<Counter />` twice gives two independent counts. This is exactly why state cannot live in a module-level variable: that would be shared by every instance and invisible to React's scheduling. ## What to say in an interview Name the return shape (value plus setter), then say the sentence that shows the model: "the state variable is a snapshot of this render, not a live reference — the setter is what tells React to produce the next snapshot." If you can add that reading the variable immediately after calling the setter still gives the old value, and that the setter identity is stable, you have covered everything the question is probing.