Splitting contexts

A context’s value is its re-render blast radius: every consumer re-renders when the value’s identity changes. React doesn’t diff inside your context value. When the value passed to a provider is a new reference, every component that calls useContext on it re-renders — regardless of which field it actually reads. So the granularity of your context is the granularity of your re-renders.

// One context, everything in it. Any change → new value object →
// EVERY useContext(AppContext) consumer re-renders, even ones that
// only read `theme` when it was `user` that changed.
const AppContext = createContext<AppState | null>(null);

function AppProvider({ children }: { children: React.ReactNode }) {
  const [user, setUser] = useState<User | null>(null);
  const [theme, setTheme] = useState<"light" | "dark">("light");
  // a fresh object literal every render → identity changes every render
  return (
    <AppContext.Provider value={{ user, setUser, theme, setTheme }}>
      {children}
    </AppContext.Provider>
  );
}

The cart reads user. The header reads theme. Both subscribe to the same context, so both re-render on either change. The blast radius is “everyone”.

Split by concern: one context per independently-changing slice. Auth state and theme state change on totally different cadences and are read by different parts of the tree. Give each its own context, and a consumer only subscribes to — and only re-renders for — the slice it actually reads.

const AuthContext = createContext<{ user: User | null; setUser: (u: User | null) => void } | null>(null);
const ThemeContext = createContext<{ theme: Theme; setTheme: (t: Theme) => void } | null>(null);

function AppProviders({ children }: { children: React.ReactNode }) {
  const [user, setUser] = useState<User | null>(null);
  const [theme, setTheme] = useState<Theme>("light");
  return (
    <AuthContext.Provider value={{ user, setUser }}>
      <ThemeContext.Provider value={{ theme, setTheme }}>
        {children}
      </ThemeContext.Provider>
    </AuthContext.Provider>
  );
}

Now useContext(ThemeContext) in the header re-renders on theme changes only; the cart, reading useContext(AuthContext), is untouched when the user toggles dark mode. The blast radius shrank from “everyone” to “everyone who reads this slice”. The axis to split on is what changes together vs. independently, not how the data is shaped on a whiteboard.

Separate state from its setters: the writers don’t need the value. A component that only changes the theme — a toggle button — has no reason to re-render when the theme changes. But if theme and setTheme live in the same context, it re-renders anyway. Split read-state into one context and the dispatch/setters into another. Setters are stable for the life of the component, so the dispatch context’s value never changes identity — its consumers re-render essentially never.

const ThemeStateContext = createContext<Theme | null>(null);
const ThemeDispatchContext = createContext<((t: Theme) => void) | null>(null);

function ThemeProvider({ children }: { children: React.ReactNode }) {
  const [theme, setTheme] = useState<Theme>("light");
  // setTheme from useState is stable across renders, so the dispatch
  // context value is referentially stable → its consumers don't re-render.
  return (
    <ThemeStateContext.Provider value={theme}>
      <ThemeDispatchContext.Provider value={setTheme}>
        {children}
      </ThemeDispatchContext.Provider>
    </ThemeStateContext.Provider>
  );
}

// A toggle button reads ONLY dispatch → never re-renders when theme changes.
function ThemeToggle() {
  const setTheme = useContext(ThemeDispatchContext)!;
  return <button onClick={() => setTheme((prev) => (prev === "dark" ? "light" : "dark"))}>Toggle</button>;
}

This is the same move useReducer + context formalizes: a state context and a dispatch context. dispatch is permanently stable, so write-only consumers cost nothing.

Stabilize the provided value with useMemo, or the split buys you nothing. A provider whose value is a fresh object literal gets a new identity every render of the provider, so every consumer re-renders every time the provider re-renders — even if no field actually changed. Splitting contexts doesn’t help if each split still hands down an unstable object. Memoize the value on its real dependencies.

function AuthProvider({ children }: { children: React.ReactNode }) {
  const [user, setUser] = useState<User | null>(null);
  // Without useMemo this object is new every render → identity churn.
  // With it, consumers re-render only when `user` actually changes
  // (setUser is already stable, so it's not in the dep list's intent).
  const value = useMemo(() => ({ user, setUser }), [user]);
  return <AuthContext.Provider value={value}>{children}</AuthContext.Provider>;
}

The state/dispatch split is the cleaner version of this: a bare theme value and a bare stable setTheme need no useMemo at all, because neither is an object literal. Reach for useMemo when the value must be a bundled object (e.g. { user, setUser }); reach for the split when you can avoid the object entirely.