Context, value identity, and the re-render storm

The mechanism: one identity check, then broadcast

Context propagation is brutally simple. When a provider re-renders, React compares the new value prop to the previous one with Object.is. If it differs, React walks the subtree, finds every component that reads this context — via useContext or use — and schedules each one for re-render. Two properties of this walk define every context bug you will meet. First, delivery bypasses memo bailouts: React.memo and shallow-equal props can stop parent-driven re-renders from descending, but a context update is delivered to subscribed descendants through memoized ancestors — the ancestors themselves stay skipped, while the consumer underneath them still re-renders. This is by design: a consumer asked for the value, so it must get the new one. Second, there is no selector: a consumer cannot subscribe to value.theme only. Any identity change of the whole value re-renders every consumer, whether the slice they read changed or not.

Now the storm in the Hook follows mechanically. value={{ user, theme, permissions, setTheme }} is an object literal in the provider’s render — a fresh identity every render. So the provider re-rendering for any reason at all (a keystroke in unrelated state, a parent update) means Object.is(prev, next) is false, means all 38 consumers re-render, means their subtrees re-render too. The contents didn’t change; the wrapper’s identity did, and identity is the only thing React checks.

// ❌ broadcast storm: new value identity on every shell render
function AppShell() {
  const [query, setQuery] = useState("");
  return (
    <AppContext.Provider value={{ user, theme, permissions, setTheme }}>
      <SearchInput value={query} onChange={setQuery} />
      <Routes />
    </AppContext.Provider>
  );
}

// ✅ fix 1: stable identity — broadcasts only when contents change
const appValue = useMemo(
  () => ({ user, theme, permissions, setTheme }),
  [user, theme, permissions] // setTheme from useState is already stable
);

// ✅ fix 0 (often better): move the unrelated state DOWN —
// the search box owns its query; the provider never re-renders on keystrokes.

Splitting contexts: state apart from dispatch

The Hook’s cruelest detail — consumers of setTheme re-rendering on every theme read path change — has a structural fix. Functions that update state have stable identities (setState from useState, dispatch from useReducer are guaranteed stable), so components that only trigger changes never need to re-render when the data changes. Put the data and the updaters in two separate contexts:

const StateContext = createContext(null);
const DispatchContext = createContext(null);

function AppProvider({ children }) {
  const [state, dispatch] = useReducer(reducer, initialState);
  return (
    <StateContext.Provider value={state}>
      <DispatchContext.Provider value={dispatch}>
        {children}
      </DispatchContext.Provider>
    </StateContext.Provider>
  );
}

Now a toolbar button that calls dispatch subscribes only to DispatchContext, whose value never changes identity — it re-renders exactly zero times when state updates. Read-heavy components subscribe to StateContext and re-render when state genuinely changes (the reducer returns a new object only when something changed). Two further refinements carry real apps: split by domain as well — ThemeContext apart from AuthContext apart from PermissionsContext — so an auth refresh doesn’t re-render every themed button; and note the {children} pattern above is itself an optimization: children are created by the caller of AppProvider, so when AppProvider’s own state changes, the children element identity is unchanged and React can skip re-rendering that subtree wholesale — the provider re-renders, the static tree under it does not.

Choosing the channel: props, context, or external store

Three delivery mechanisms, three honest selection criteria. Prop drilling is explicit dataflow — every hop visible, refactoring traceable, no hidden subscriptions. For 2–3 levels it is simply correct, and component composition (passing JSX as children) removes most “drilling pain” without any context at all. Its cost is ceremony across many levels and re-renders along the chain unless memoized. Context is built for low-frequency, wide-fanout values: theme, locale, current user, router location, feature flags — things that change a few times per session and that dozens of components read. Its hard limits: no selectors (every consumer re-renders on any value identity change) and update cost proportional to consumer count. External stores (Zustand, Redux, Jotai — all built on useSyncExternalStore) hold state outside React and let each component subscribe with a selector: re-render only when selector(state) returns a different value than last time. That is subscription granularity — the thing context cannot give you — and it is what makes high-frequency state (keystroke-level filters, websocket tickers, drag positions) viable at scale. The store-backed hook compares the selected slice, not the whole state object, so the trading table re-renders only rows whose ticker moved.

When you reach for context, ask: how often does this value change, and how many components need it? The decision in one pass: changes rarely, read widely → context. Changes constantly, or different consumers need different slices → external store with selectors. Visible 2–3 hops → just pass props; reach for machinery only when the explicit version measurably hurts. The common production failure is the inverse: app state of every frequency dumped into one context “to avoid Redux”, which re-derives the Hook’s storm — and then a hand-rolled subscription system grows inside the provider, which is an external store, written badly, without useSyncExternalStore’s tearing guarantees.