When to reach for a store

The default ladder is colocate → lift → context. A store is the rung you climb to only when those stop scaling. Most “we need a store” instincts are really “this state is two levels too low” or “this prop drilled four levels”. Lifting and context fix those for free, with no new dependency and no second source of truth. The senior move is to exhaust the ladder first.

// rung 1: colocate — state lives next to its only user
function SearchBox() {
  const [q, setQ] = useState("");
  return <input value={q} onChange={(e) => setQ(e.target.value)} />;
}

// rung 2: lift — nearest common parent owns shared state
// rung 3: context — stop prop-drilling low-frequency shared state (theme, auth user)

A store is rung 4. You reach for it when rungs 1–3 produce either prop-drilling at depth you can’t refactor away, or a context whose updates re-render too much. Not before.

Pressure one: distant branches. When two far-apart subtrees share state, lifting forces it absurdly high and context becomes a wide net. If a command palette in the header and a detail panel in a deep route both need the same selection, the nearest common parent is the app root — so lifting there means threading props or a provider through everything between. A store lets each consumer subscribe directly, with no shared ancestor doing the plumbing.

// store consumed by two unrelated branches — no common parent in between
const useSelection = create<{ id: string | null; select: (id: string) => void }>(
  (set) => ({ id: null, select: (id) => set({ id }) })
);

function HeaderPalette() {
  const select = useSelection((s) => s.select); // subscribes to nothing that changes
  return <button onClick={() => select("user-42")}>Jump to user</button>;
}
function DeepDetailPanel() {
  const id = useSelection((s) => s.id); // re-renders only when id changes
  return <p>Selected: {id ?? "none"}</p>;
}

The store flattens the topology: subscription replaces a chain of intermediaries that don’t care about the state.

Pressure two: high-frequency updates that would storm context. Context has no selector — every consumer of a provider re-renders on every value change, even consumers that only read an unrelated field. For state that updates many times a second (a live cursor position, a dragging gesture, a streaming counter, a canvas), a single context turns one update into a tree-wide render storm. A store subscribes per-selector, so a component re-renders only when its slice changes.

// high-frequency: pointer moves fire dozens of times per second
const useCursor = create<{ x: number; y: number; move: (x: number, y: number) => void }>(
  (set) => ({ x: 0, y: 0, move: (x, y) => set({ x, y }) })
);

function Crosshair() {
  // only this component re-renders on move — siblings reading other slices don't
  const { x, y } = useCursor((s) => ({ x: s.x, y: s.y }));
  return <line style={{ transform: `translate(${x}px, ${y}px)` }} />;
}

The same move through context would re-render every consumer of that provider, dozens of times a second. The store’s selector is what makes high-frequency state affordable.

Pressure three and four: persistence across routes, and devtools. A store lives outside the component tree, so it survives unmounts — and exposes a single inspectable state object. Lifted state and context state die when their owning subtree unmounts on a route change; preserving it means hoisting it above the router, which often means… a store. A store also gives you one place to inspect, time-travel, and log every transition — the Redux DevTools / Zustand middleware story — which is genuine value when state transitions are complex enough that “what changed and why” is a real debugging cost.

import { persist } from "zustand/middleware";

// survives route changes and reloads; one inspectable object
const useDraft = create(
  persist<{ text: string; setText: (t: string) => void }>(
    (set) => ({ text: "", setText: (text) => set({ text }) }),
    { name: "draft" } // persisted to storage, restored across routes/reloads
  )
);

These four pressures — distance, frequency, persistence, debuggability — are the only reasons that beat the simpler ladder. If none apply, you don’t have a store-shaped problem.