React Concurrent Rendering and Legacy State Management Integration

Answer first

useEffect execution order with discarded concurrent updates: No effect runs for a render that is interrupted or discarded. React only commits effects after a render is committed to the DOM. Discarded renders contribute neither effects nor cleanups. Effect ordering guarantees — child before parent, cleanup of previous commit before effects of next commit — apply only to committed updates.

External store subscriptions when a render is interrupted: With the supported API useSyncExternalStore, React re-reads the store snapshot between render and commit. If the snapshot changed during the render, React discards that render and restarts synchronously with the new snapshot. This prevents tearing but removes the update from concurrent scheduling for that change.

Confirmed facts

• Effects run post-commit only. Interrupted or abandoned renders never execute useEffect or useLayoutEffect.
• Render phase must be pure. React may render a tree multiple times or start a render and abandon it before commit.
• useSyncExternalStore is the supported integration point for external state in React 18+. It provides getSnapshot and subscribe contracts React uses to detect changes during the render-commit window.
• Concurrent semantics require createRoot. Legacy ReactDOM.render mode never interrupts renders.

Likely explanation for legacy synchronous stores

Reading a legacy synchronous store directly via useState + manual useEffect subscription gives React no way to detect a mutation that occurs mid-render. A store mutation during a transition can cause different components to read different values in the same committed frame — tearing — because React cannot re-read a consistent snapshot.

With useSyncExternalStore, the store is sampled at render start and again before commit. A change forces a synchronous restart, so all components in the committed tree see the same snapshot. The restart is synchronous and therefore not interruptible, which is the intended safety trade-off.

Steps needed for this case

1. Confirm concurrent mode is active. Check you use createRoot and updates you want to be interruptible are wrapped in startTransition.
2. Wrap the legacy store with useSyncExternalStore instead of manual useEffect subscription:

   function useLegacyStore() {
     const getSnapshot = () => legacyStore.getState();
     const subscribe = (cb) => {
       const unsub = legacyStore.subscribe(cb);
       return unsub;
     };
     return useSyncExternalStore(subscribe, getSnapshot);
   }

3. Make getSnapshot cheap and referentially stable. Do not return a fresh object/array each call; return the same reference when state is unchanged, or memoize a selector.
4. Move side effects out of render. Keep subscriptions inside the hook, and keep DOM/network effects in useEffect which will only fire after a successful commit.
5. Verify with StrictMode. In development StrictMode intentionally double-invokes renders and effects. The integration should survive without duplicate subscriptions or leaks.

Uncertainty note: The exact interruption behavior depends on priority scheduling and whether the update is a transition. Without knowing the legacy library's subscribe contract — synchronous vs asynchronous notification, and whether it can emit during React's render — the risk of missed updates or extra synchronous restarts cannot be fully quantified.

One diagnostic detail that changes the recommendation: Are you mounting with createRoot and using startTransition for the updates in question? If not, concurrent interruption will not occur and tearing risk is limited to normal synchronous updates.