Your team wants to adopt React 19 transitions across a large app whose shared state lives in hand-written module-level stores that components read directly during render. How do you reason about the tearing risk that introduces, and what do you do about it?

## What actually changed for the team Before transitions, this app was effectively rendering synchronously, and reading a module-level object during render was sound — no window existed in which the value could move mid-render. Adopting transitions opens that window. Nothing in the state layer got worse; a latent constraint became active. Framing it that way matters, because it explains to the team why code that has worked for three years is suddenly a defect class, and it sets the scope: this is a one-time property of the state layer, not an ongoing tax on feature work. ## The audit: three questions per source Enumerate every shared mutable source, then score it. **1. Is it read during render?** Values consulted only inside event handlers or effects cannot tear — those reads happen at a single instant, not spread across a render pass. This question alone eliminates a surprising share of the inventory. **2. Can it change while the screen is up?** A configuration object assigned once at boot and never reassigned cannot produce two different reads no matter how the render is sliced. Frequently mutated sources — carts, selections, connection status, live feeds — are the real population. **3. Would disagreement be visible and harmful?** This is judgment, and it is where a lead earns the title. A total that contradicts the list beside it is a correctness bug users screenshot and file. A theme flag briefly disagreeing between two panels is a cosmetic blip nobody will ever notice. Rank accordingly rather than declaring everything critical. The output is a short list of sources that fail all three, a medium list that fails one or two, and a long tail that needs nothing. Migrate the first list; schedule the second; document the third so the next person does not re-litigate it. ## Make the safe path the only path A per-component rule ("do not import the store directly") decays. The durable move is structural: each store exposes exactly one hook, the store object itself stops being importable from feature code, and a lint boundary enforces it. The point is not elegance — it is that new code physically cannot reintroduce the unsafe read, so the audit does not have to be repeated every quarter. The alternative fix is equally legitimate and often cheaper: hoist the value to a single owner and pass it down. A value produced by the render pass cannot tear, so if a store exists only because passing props was tedious, the honest answer may be to delete the store rather than to wrap it. ## Budget the cost, do not pretend it is free Tearing-safe reads are not a free upgrade. Those updates render as blocking work rather than deferrable work, which is precisely the property transitions were adopted to obtain. Two consequences worth planning for: - **Snapshot width.** A component that reads the entire store state re-renders on every unrelated change. Narrow snapshots — one field, ideally a primitive — keep both the update count and the blocking cost small. - **Read breadth.** If half the tree reads one hot store, every change to it becomes a broad blocking render. That is an argument for pushing reads down to the components that genuinely need them, or for splitting one busy store into several. A team that migrates everything to the safe path and measures nothing can end up with an app that is consistent and less responsive than before, which is a bad trade to have made silently. ## Sequencing the rollout A reasonable order: migrate the top-risk stores first, *then* enable transitions on the surfaces that need them, rather than the reverse. Adopting transitions first turns a known migration into an intermittent bug hunt — and this defect class reproduces poorly, appearing on slow devices and under load, healing itself on the next render, and leaving nothing in the logs. Paying for it in scheduled work is far cheaper than paying for it in unreproducible tickets. It is also worth deciding up front what evidence would tell you a source you *chose* to leave alone was the wrong call, so the accepted risks stay accepted on purpose rather than by neglect. ## The organisational point The genuinely principal-level move is refusing the two easy extremes: "rewrite the whole state layer before we touch transitions" and "ship transitions and fix inconsistencies as they are reported." The first spends months on sources that could never tear; the second converts a tractable audit into an untraceable bug class. The defensible position is a ranked, bounded migration plus a structural guarantee that closes the door behind it.