Context with a reducer

A reducer puts every transition in one place — so the state shape and its rules live together, not scattered across consumers. With useState, each component that mutates the cart re-implements “does this item exist? then increment, else push”. A reducer makes the transition a named, exhaustive function; components just announce intent with dispatch.

type CartItem = { id: string; qty: number };
type CartState = { items: CartItem[] };
type CartAction =
  | { type: "add"; id: string }
  | { type: "remove"; id: string }
  | { type: "clear" };

function cartReducer(state: CartState, action: CartAction): CartState {
  switch (action.type) {
    case "add": {
      const existing = state.items.find((i) => i.id === action.id);
      const items = existing
        ? state.items.map((i) => (i.id === action.id ? { ...i, qty: i.qty + 1 } : i))
        : [...state.items, { id: action.id, qty: 1 }];
      return { items };
    }
    case "remove":
      return { items: state.items.filter((i) => i.id !== action.id) };
    case "clear":
      return { items: [] };
  }
}

The reducer is a pure function with no React in it — trivially unit-testable, and the discriminated union makes an unhandled action a type error. The “add bumps quantity” rule now exists exactly once.

Hand out state and dispatch through two separate contexts — not one object. The naive version is <CartContext.Provider value={{ state, dispatch }}>. The problem: that value object is a new reference on every render, so every consumer re-renders even if it only ever calls dispatch. Splitting them lets a component subscribe to exactly what it needs.

const CartStateContext = createContext<CartState | null>(null);
const CartDispatchContext = createContext<React.Dispatch<CartAction> | null>(null);

export function CartProvider({ children }: { children: React.ReactNode }) {
  const [state, dispatch] = useReducer(cartReducer, { items: [] });
  return (
    <CartStateContext.Provider value={state}>
      <CartDispatchContext.Provider value={dispatch}>
        {children}
      </CartDispatchContext.Provider>
    </CartStateContext.Provider>
  );
}

A button that only adds items reads the dispatch context and never the state context — so when the cart changes, that button does not re-render.

The dispatch context never triggers re-renders, because useReducer returns a dispatch whose identity is stable for the component’s whole lifetime. React guarantees dispatch (like a setState updater) is referentially stable across renders. A context only re-renders its consumers when the provider’s value changes by Object.is. Since the dispatch reference never changes, the dispatch context’s value never changes, so its consumers never re-render from it. Only the state context’s value changes per update, and only its readers re-render.

export function useCartDispatch() {
  const ctx = useContext(CartDispatchContext);
  if (!ctx) throw new Error("useCartDispatch must be used inside <CartProvider>");
  return ctx; // stable forever — safe to put in deps, safe to pass down
}

export function useCart() {
  const ctx = useContext(CartStateContext);
  if (!ctx) throw new Error("useCart must be used inside <CartProvider>");
  return ctx;
}

This is the whole efficiency trick: the writers (action triggers) are decoupled from the readers (state displays). In a single-context design you’d reach for useMemo on the value and memo on children to claw this back; the split gives it to you structurally, for free.

Know the failure mode: this pattern is for moderate client state with real transitions — not server state, and not huge / high-frequency state. Two misuses sink it. First, putting server state here (the product catalog, the user’s orders) means you hand-roll caching, refetching, staleness, and dedup that a query library already solves — context + reducer has no concept of “this data came from the network and can go stale”. Second, when the state is large or updates many times per second (a live cursor, a big editor document, per-keystroke form state read by hundreds of nodes), even the split-context approach re-renders every state reader on every change, because context can’t do selective subscriptions.

// WRONG: server state shoved into a reducer/context
dispatch({ type: "ordersLoaded", orders }); // who refetches? when is this stale?
// → use TanStack Query / SWR: useQuery(['orders', userId], fetchOrders)

// WRONG: high-frequency, selector-needing state in context
// every keystroke re-renders all 200 fields that read the form context
// → use an external store (Zustand/Redux + selectors, or useSyncExternalStore)

Context + reducer sits in the middle: bigger than useState lifted one level, smaller than a store. Match it to that band.