Reducers and context: turning scattered setState into testable transitions

Transitions, not fields: what useReducer actually changes

A form with ten useState calls has no architecture — it has ten independent values and a prayer that every event handler updates the right subset. The failure mode is invariant drift: a rule like “total reflects discount and shipping” lives in no single place, so each new handler is a chance to update four of the five fields it should. useReducer inverts the structure. State becomes one object; updates become actions — named events describing what happened (promo-applied), not which fields to write (setDiscount + setTotal). The reducer is the single place where events turn into the next state:

function checkoutReducer(state, action) {
  switch (action.type) {
    case "promo-applied": {
      const discount = computeDiscount(state.items, action.code);
      return withTotals({ ...state, promoCode: action.code, discount });
    }
    case "shipping-selected": {
      return withTotals({ ...state, shipping: action.method });
    }
    default:
      throw new Error(`Unknown action: ${action.type}`);
  }
}

// withTotals is the ONE place the invariant lives:
function withTotals(state) {
  return { ...state, total: subtotal(state) - state.discount + shippingCost(state) };
}

const [state, dispatch] = useReducer(checkoutReducer, initialCheckout);
// Handlers shrink to intent: dispatch({ type: "promo-applied", code });

Mechanically, dispatch schedules a re-render and React calls your reducer with the current state and the action during the next render — which is why the reducer must be pure: no fetches, no Date.now(), no mutation of the incoming state (in StrictMode the reducer is double-invoked to catch exactly this). Components shrink to dispatching intent; the decision logic leaves the component entirely.

Pure logic is testable logic

Ask yourself: how do you write a regression test for a bug that only appears when two events fire in a specific order, with no DOM? With a reducer, the answer is three lines. Because the reducer is a pure function (state, action) => state, the most bug-prone logic in the feature — multi-field invariants, edge-case sequencing — becomes unit-testable without rendering anything. The Hook’s regression test is three lines of replay: start from a known state, dispatch shipping-estimate-loaded then promo-applied, assert the total. No JSDOM, no act(), no mocked network — reducer tests run in microseconds and pin down sequences, which is precisely where scattered-setState bugs hide. This is the underrated payoff: teams adopt reducers “for organization” and discover the real win is that state logic finally has the same test discipline as the rest of the codebase. Tradeoff: the ceremony is real — action types, a switch, an indirection between the click and the write. For two fields with no invariants, useState is strictly better; a reducer earns its keep when fields update together under rules.

Splitting state and dispatch: re-render hygiene as architecture

To share reducer state across a feature subtree, you pass it through context — and here the re-render hygiene from unit 02 becomes an architectural decision. A context re-renders every consumer when its value changes identity. If you publish { state, dispatch } as one object, every consumer re-renders on every state change — including toolbar buttons that only ever dispatch. The fix is structural: two contexts.

const CheckoutStateContext = createContext(null);
const CheckoutDispatchContext = createContext(null);

function CheckoutProvider({ children }) {
  const [state, dispatch] = useReducer(checkoutReducer, initialCheckout);
  return (
    <CheckoutDispatchContext.Provider value={dispatch}>
      <CheckoutStateContext.Provider value={state}>
        {children}
      </CheckoutStateContext.Provider>
    </CheckoutDispatchContext.Provider>
  );
}

React guarantees dispatch is referentially stable across renders — the dispatch context’s value never changes, so write-only components (buttons, menu items, the express-checkout banner) subscribe to it and never re-render from state changes. Read-only components subscribe to the state context and re-render when state changes — which is honest, because they display it.