A custom hook subscribes to an external store inside useEffect and mirrors the current value into useState on every change. Under React 19 concurrent rendering, why can components using that hook still show inconsistent values in one commit?

## The pattern under discussion ```js function useStoreValue(store) { const [value, setValue] = useState(() => store.getState()); useEffect(() => store.subscribe(() => setValue(store.getState())), [store]); return value; } ``` This was the standard way to connect a component to shared external state for years, and under synchronous rendering it was sound. Concurrent rendering breaks it, and understanding *why* is the point of the question — not memorising a replacement. ## Effects run after the commit, never inside the render The first thing to state plainly: React does not run effects between two components of a render pass. The order is render everything, commit, then run effects. So while the render is in flight — the exact window in which the store can move — the subscription mechanism is dormant. It has no opportunity to reconcile anything, because it is not running. That single fact rules out this pattern as a fix. Whatever the subscription does, it does it after the inconsistent tree has already been assembled. ## Failure one: seeding versus mirroring The hook has two different paths to a value, and they are read at different times: - A component that is **already mounted** holds a copy in state, last written by the subscription callback. - A component that **mounts during this render** runs the lazy initializer and reads the store directly, at the instant its own body executes. Now suppose the store changes partway through a render that mounts a new component: ``` render <Total/> (already mounted, state copy holds 3) | | React yields; something calls store.setState(4) v render <Badge/> (mounting now: useState(() => store.getState()) -> 4) commit Total shows 3, Badge shows 4 ``` Both components used the same hook, and the commit is internally contradictory. The subscription will fire afterwards and eventually align them, but a torn frame was already shown. ## Failure two: updates from a subscription have no special standing When the subscription callback calls the setter, that is an ordinary state update. React treats it exactly like an update from a click handler or a timer — it can be batched with others, and it is scheduled according to normal priority rules. Nothing about it tells React "several components are mirroring one shared fact and must all move together." React has no way to know that the copy inside `Total` and the copy inside `Badge` are supposed to be the same number, because as far as the reconciler is concerned they are two unrelated pieces of component state that happen to hold equal values most of the time. That is the deeper problem. The pattern turns *one* shared fact into *N* independent copies, and consistency across N independent state values is not something React ever promised. ## Failure three: nothing is verified before commit A tearing-safe read works because React records what the component rendered with and re-checks it before putting the tree on screen. The mirroring pattern gives React nothing to check. From the reconciler's point of view, the value came out of ordinary state, which it already considers trustworthy. There is no signal that this particular state is a shadow of something that lives elsewhere and may have moved. There is also a related gap in the same pattern — the store can change between the render that read it and the moment the effect actually subscribes, so an update can be missed entirely. That is a subscription-setup concern rather than a tearing concern, but it comes from the same root cause: the effect runs too late to cover the render. ## What actually changes with a tearing-safe read The substantive difference is not *where the subscription lives* but *whether the render-time read is visible to React*. Once React knows a component's output was derived from an external value, it can: - record the exact value the component rendered with; - re-read it before commit and compare; - discard and redo the render if it moved, rather than committing a mixed tree; - treat all components reading that store as participants in one update instead of N unrelated ones. None of that is achievable from inside an effect, at any level of cleverness, because effects are outside the render. ## How to answer this out loud Lead with the timing: effects run after commit, so the subscription cannot influence the render where the inconsistency forms. Then give the concrete divergence — new mounts read the store directly while existing components hold a copy. Then land the general point: the pattern replaces one shared fact with many independent state copies, and React never guaranteed that independent state values stay in step.