Context for low-frequency state

A context value change re-renders every consumer — there is no partial subscription. When a Provider’s value is a new reference, React marks every component that called useContext for that context as needing to re-render. It does not matter that a consumer only reads value.theme and the thing that changed was value.locale; the unit of change is the whole value, and the unit of notification is “all consumers”. React.memo does not save you: a memoized component still re-renders when a context it consumes updates, because context is a separate channel from props.

const AppContext = createContext<{ theme: Theme; locale: string } | null>(null);

// reads only `theme`, but re-renders whenever `locale` changes too —
// because the value reference changed, and memo can't block a context update
const ThemeBadge = memo(function ThemeBadge() {
  const { theme } = useContext(AppContext)!;
  return <span data-theme={theme} />;
});

This is the single fact the whole pattern hangs on: context is broadcast, all-or-nothing, to every consumer.

Because change is broadcast, context fits state that changes rarely and is read widely. Theme, the authenticated user, locale, feature flags — these flip seconds or minutes apart (or once per session) and are needed in dozens of scattered places. A broadcast on every change is cheap when changes are rare, and prop-drilling them would be miserable. That is the exact shape context was designed for: low-frequency, widely-read. The re-render cost is real but paid almost never; the prop-drilling cost is avoided constantly.

// good fit: changes on a user click, read all over the app
const ThemeContext = createContext<ThemeApi | null>(null);

export function useTheme() {
  const ctx = useContext(ThemeContext);
  if (!ctx) throw new Error("useTheme must be used within <ThemeProvider>");
  return ctx;
}

If your candidate state changes many times per second, it is the opposite shape — and context is the wrong tool, no matter how widely it’s read.

Done right: keep the provider’s value stable, so consumers re-render only on real changes. The cost of context is paid whenever the value reference changes — so an unstable value (a fresh object literal every render) re-renders all consumers on every parent render, even when nothing meaningful changed. Memoize the value, and keep setters stable so they never force a value change. A clean ThemeContext flips the value only when the theme actually flips.

function ThemeProvider({ children }: { children: React.ReactNode }) {
  const [theme, setTheme] = useState<Theme>("light");

  // toggle is stable; useState's setter identity is already stable
  const toggle = useCallback(() => setTheme((t) => (t === "light" ? "dark" : "light")), []);

  // value reference changes ONLY when `theme` changes → consumers re-render only then
  const value = useMemo(() => ({ theme, toggle }), [theme, toggle]);

  return <ThemeContext.Provider value={value}>{children}</ThemeContext.Provider>;
}

Without the useMemo, { theme, toggle } is a new object on every ThemeProvider render, so any unrelated state change near the root would broadcast to every consumer for nothing.

Failure mode: put high-frequency state in context and every consumer becomes a re-render storm. Field values that change on each keystroke, mouse position that changes on each mousemove, an animation frame that changes 60 times a second — route any of these through a context and every consumer re-renders at that frequency, including ones that don’t even read the changing field. This is the classic context anti-pattern: a “form context” holding live input values, where typing one character re-renders every field, the submit button, and the validation summary.

// ANTI-PATTERN: live values in context → typing re-renders the whole form tree
const FormContext = createContext<{ values: Record<string, string>; set: Fn } | null>(null);

function Field({ name }: { name: string }) {
  const { values, set } = useContext(FormContext)!; // re-renders on EVERY keystroke,
  return <input value={values[name]} onChange={(e) => set(name, e.target.value)} />; // in any field
}

The fix is not to memoize harder — it’s to stop broadcasting fast state. Keep high-frequency state local (each field owns its own useState), lift only what’s truly shared, or use a store with selector subscriptions (useSyncExternalStore, Zustand, Jotai) so a component re-renders only when its slice changes. Context broadcasts; fast state needs targeted subscription.