When a component reads an external store through useSyncExternalStore, how does React detect that the store changed partway through a render, and what does it do so the committed tree stays consistent?

## The core idea: make the read visible React cannot verify a value it does not know was read. A component that reaches into a module object during render just looks like a function that returned elements. The tearing-safe path exists to close that gap: the component asks React for the value, React performs the read on its behalf, and now React has something it can check. Everything else is bookkeeping around that one shift. ## Step one: record what was rendered with During the render pass, React calls the store's snapshot function and stores the returned value on the fiber alongside the rest of that component's hook state. That recorded value is the claim the render is making: *this component's output was computed from exactly this value.* ## Step two: verify before commit A render is not a commit. Between finishing the tree and putting it on screen, React re-reads the snapshot for every fiber that consulted a store, and compares the fresh read against the recorded one with `Object.is` — the same identity comparison React uses for bailing out of re-renders elsewhere. Two outcomes: - **Equal.** Nothing moved during the render. The tree is coherent and gets committed. - **Not equal.** The store changed somewhere between the read and now, so the tree may contain values from two different moments. React does not attempt to patch the affected components — it discards the work and renders again with the current value. Redoing a render is cheap in the sense that matters: a render pass produces no DOM changes until commit, so throwing one away has no user-visible cost beyond the time spent. ## Step three: stop yielding for this update Re-checking is not enough on its own, because a re-render that is itself spread across several tasks could tear again, and a store that changes rapidly could keep invalidating attempts. So React also renders the store-driven update as blocking work rather than deferrable work: it does not spread that re-render across tasks in a way that reopens the window. This is the real tradeoff of the mechanism, and interviewers like to hear it named. External-store reads buy consistency by surrendering some of the interruptibility that concurrent rendering exists to provide. A store that changes constantly and is read by a large subtree can therefore claw back the responsiveness you adopted transitions to gain. ## Why snapshot identity must be stable The comparison is identity-based, so the snapshot function must return the *same value* whenever the store has not changed. Derive a new object or array on every call and the check always reports a change — React re-renders, re-reads, sees another new object, re-renders again. In development React surfaces this by warning that the result of the snapshot function should be cached to avoid an infinite loop. The two ways out are the same ones any cache uses: ```js // Wrong: a new array every call, so identity never matches. const getVisible = () => state.items.filter((i) => !i.done); // Right: recompute only when the store's version actually advances. let cache = { version: -1, value: [] }; function getVisible() { if (cache.version !== state.version) { cache = { version: state.version, value: state.items.filter((i) => !i.done) }; } return cache.value; } ``` Either the store hands out an immutable state object that it replaces wholesale on change (so identity naturally tracks change), or the derivation is memoised against a version marker. Returning a primitive — a number, a string, a boolean — is trivially stable and is the simplest correct answer when a component only needs one field. ## Why the check has to happen at commit time, not later A post-commit correction would still put the inconsistent frame on screen for at least one paint. The whole value of the mechanism is that the contradictory tree is never shown, which is only achievable while React still owns the work and has not handed it to the DOM. ## What to say in an interview Three beats: React records the value each component rendered with; it re-reads and compares by identity before committing and redoes the render if it moved; and it renders that update as blocking work so the redo cannot tear either. Then add the constraint that pays for it — the snapshot must be referentially stable, or the identity check misfires into an endless re-render loop.