External stores: useSyncExternalStore, selector subscriptions, and tearing

The contract: subscribe, getSnapshot, and the tearing check

State React owns (useState, useReducer) is versioned with the fiber tree, so concurrent rendering can never see two versions in one pass. State living outside React — a module singleton, a WebSocket cache, navigator.onLine — has no such guarantee: an interruptible render can span a mutation, and components rendered before and after it disagree in the same committed frame. That is tearing, and useSyncExternalStore is the contract that prevents it:

const value = useSyncExternalStore(
  subscribe,    // (callback) => unsubscribe; call callback on every store change
  getSnapshot,  // () => current value; MUST return cached value if nothing changed
  getServerSnapshot // optional: value for SSR + hydration
);

subscribe registers React’s own change-callback with your store and returns a cleanup. getSnapshot returns the current value — and must return the same reference until the store actually changes, because React calls it repeatedly and uses Object.is to decide if anything moved. Return a fresh object each call (() => ({ ...state })) and React sees an eternally-changing store: the infamous “The result of getSnapshot should be cached” error, followed by an infinite re-render loop. The anti-tearing mechanism: when a store update arrives during a non-blocking render, React re-checks snapshots and forces the conflicting update to render synchronously, sacrificing time-slicing for consistency. Your old useEffect-subscription hook had a second flaw besides tearing: updates firing between render and effect-subscription were silently lost — uSES closes that gap too.

Zustand: selector subscriptions on top of the contract

useSyncExternalStore is deliberately low-level — one store, whole-value subscription. Zustand is what the pattern looks like productized. The store is created outside React as a module-level singleton — no provider, no context, importable from anywhere including non-React code:

const useCartStore = create((set, get) => ({
  items: [],
  promo: null,
  addItem: (item) => set((s) => ({ items: [...s.items, item] })),
  total: () => get().items.reduce((sum, i) => sum + i.price, 0),
}));

// Component subscribes to a SLICE via selector:
function CartBadge() {
  const count = useCartStore((s) => s.items.length);
  return <span>{count}</span>; // re-renders ONLY when items.length changes
}

The mechanism is selector subscription: the hook runs your selector against the snapshot, and re-renders the component only when the selector’s output changes (Object.is by default; a custom equality like shallow-compare is opt-in). A promo-code write re-renders zero components that only selected items.length. Compare context: every consumer re-renders on any change to the value’s identity, full stop. The classic self-inflicted wound is a selector returning a fresh object — useCartStore((s) => ({ a: s.a, b: s.b })) — new reference every snapshot, re-render on every store write, the precision silently gone (fix: two selectors, or shallow equality).

When external beats context — and when state should bypass React entirely

Before reaching for an external store, ask: how many consumers re-render per write, and how often do writes happen? The decision is not fashion; each side has a mechanism. Write-heavy state: context re-notifies every consumer per write; a store notifies only matching selectors — at 20 writes/second with 50 consumers, that is 1,000 component renders per second versus a handful. Cross-tree access: a store is a module import — event handlers, route loaders, analytics, and code outside the provider hierarchy can read and write it; context requires being under the provider. Tooling: middleware (persist, immer, devtools with action history) attaches at the store boundary. Context still wins for low-write, scope-shaped values — theme, locale, the current user — where the provider hierarchy is the feature and a dependency is overhead.