Why can a value held in React state with useState or useReducer never tear during a concurrent render, while a value read from a mutable module-level object can?

## The difference in one sentence React state is *derived per render pass*; external data is *read live*. Everything else follows from that. ## How React state gets its value When you call a setter, React does not immediately overwrite a variable somewhere. It appends an update to a queue attached to that component's fiber — React's internal record of the component — and marks that work as pending. Later, when React renders, it walks the tree and, for each component, computes the state by replaying that fiber's queued updates. Two consequences matter here: 1. **The inputs to a render pass are decided when the pass begins.** A pass renders a chosen set of pending work. Updates that arrive afterwards belong to a *future* pass. They do not reach backwards into components already rendered in the current one. 2. **A pass never mixes versions.** Because state is recomputed from the queue by that pass, every component the pass renders sees state consistent with that pass, whether it was rendered in the first slice or the fifth. So even though the render was interrupted, split, and resumed, the state it committed is one coherent snapshot. ## What happens when an update lands mid-render Nothing sneaky. If a higher-priority update arrives while a render is in flight, React does not splice the new value into a half-finished tree — it abandons or defers that render and does the work again with the new information. The abandoned render is never committed, so the user never sees the mixture. Discarding work is exactly the price React pays for consistency, and it can afford it because a render pass produces no side effects on the DOM until commit. React also maintains two trees: the one currently on screen and the work-in-progress one it is building. Only a completed work-in-progress tree is swapped in. There is no moment where half the new tree is live. ## Why an external object cannot offer any of this Consider: ```js export const session = { user: null }; function Greeting() { return session.user ? `Hi ${session.user.name}` : 'Sign in'; } ``` When `Greeting` runs, `session.user` is evaluated right then. There is no queue, no version, no notion of "the value belonging to this render pass" — the property read reflects the object's state at that microsecond. If React renders `Greeting`, yields, some code assigns `session.user`, and React then renders a sibling that reads the same object, the two components have honestly read two different worlds and both results get committed. The object is not doing anything wrong. It simply has no way to answer the question React needs answered: *what was your value for the render that is currently in progress?* ## The same reasoning covers props Props are computed by a parent during the same render pass, from that parent's state and its own props. They inherit the pass's consistency, which is why a value threaded down from one owner cannot tear either. This is why "lift the value to one owner and pass it down" is a genuine fix and not merely a style preference — it converts an out-of-band read into a value produced by the render itself. ## The common misconceptions - *"Immutability is what saves useState."* Not quite. You can put a mutable object in state and mutate it later; then you are back to reading live data and can tear again. The protection comes from the value being decided by the render pass, not from the value's own immutability. - *"Batching prevents it."* Batching decides how many render passes happen. Consistency inside a pass is a separate guarantee and holds even for a single unbatched update. - *"Refs behave like state here."* They do not. A ref's `current` is a live mutable cell, exactly like a module variable. Reading `ref.current` during render is an out-of-band read and can disagree across a yield — which is one reason reading refs during render is discouraged. ## What to say in an interview State the mechanism, then the contrast: React state is recomputed by the render pass from queued updates, so one commit is one version; external data is read at whatever instant each component happens to run, and a concurrent render supplies several such instants. The problem is not that external data is mutable — it is that React has no way to pin it to a pass unless it is told about the read.