useReducer: state changes as a pure function

When several pieces of state change together, or the next state depends on rules that are worth testing on their own, move the logic out of the component into a reducer: a function (state, action) => nextState.

function cartReducer(state: Cart, action: CartAction): Cart {
  switch (action.type) {
    case "add":
      return { ...state, items: [...state.items, action.item] };
    case "clear":
      return { ...state, items: [] };
    default:
      return state;
  }
}

function Cart() {
  const [cart, dispatch] = useReducer(cartReducer, { items: [] });
  return <button onClick={() => dispatch({ type: "clear" })}>Clear</button>;
}

The component now says what happened (dispatch({ type: "clear" })) and the reducer decides what that means for the state. dispatch follows the same rules as a state setter: it queues the action, the current render's cart does not change, and React re-renders with the result. If the reducer returns the very same state object, Object.is says nothing changed and React can skip the re-render — which is why the default branch returns state itself rather than a copy.

Why "reducer"

It is the same shape of function Array.prototype.reduce takes. Replaying a list of actions through a reducer is literally a reduce call, which also makes reducers trivial to unit test without rendering anything:

1function counterReducer(state, action) {2  switch (action.type) {3    case "increment":4      return { count: state.count + 1 };5    case "add":6      return { count: state.count + action.by };7    case "reset":8      return { count: 0 };9    default:10      return state;11  }12}13 14export function run() {15  const actions = [16    { type: "increment" },17    { type: "add", by: 10 },18    { type: "typo" },19    { type: "increment" },20  ];21  const initial = { count: 0 };22  const final = actions.reduce(counterReducer, initial);23  const unknown = counterReducer(final, { type: "typo" });24  return { final, initialUntouched: initial, unknownReturnsSameObject: unknown === final };25}

Pure, or it breaks

React may call a reducer more than once for the same action — in development Strict Mode it deliberately calls it twice and keeps one result. A pure reducer gives the same answer both times. One that mutates its input, reads a counter, calls Date.now() or makes a request does not:

1let nextId = 1;2function impureReducer(state, action) {3  if (action.type === "add") return [...state, { id: nextId++, text: action.text }];4  return state;5}6function pureReducer(state, action) {7  if (action.type === "add") return [...state, { id: action.id, text: action.text }];8  return state;9}10 11// Strict Mode in development: call twice, keep the second result.12function strictDispatch(reducer, state, action) {13  reducer(state, action);14  return reducer(state, action);15}16 17export function run() {18  let impure = [];19  impure = strictDispatch(impureReducer, impure, { type: "add", text: "milk" });20  impure = strictDispatch(impureReducer, impure, { type: "add", text: "eggs" });21 22  let pure = [];23  pure = strictDispatch(pureReducer, pure, { type: "add", id: 1, text: "milk" });24  pure = strictDispatch(pureReducer, pure, { type: "add", id: 2, text: "eggs" });25 26  return { impureIds: impure.map((t) => t.id), pureIds: pure.map((t) => t.id) };27}

In this model the impure version handed out ids 2 and 4 for two adds, because each action was processed twice and the outer counter moved twice. In a real app the exact numbers depend on how often React calls the reducer; what matters is that they are not 1 and 2. Generate ids, timestamps and random values in the event handler and put them in the action; the reducer only reads them.

useReducer or useState

Both are fine. Reach for a reducer when one event updates several fields together, when the transitions are complex enough to deserve tests, or when many handlers would otherwise repeat the same update logic. Keep useState for independent values like an open/closed flag.

Common mistakes

• Mutating state and returning it. The returned reference is the old one, so React may skip the render, and Strict Mode's second call sees already-mutated input.
• Side effects in the reducer (fetching, logging analytics, generating ids). Strict Mode runs them twice in development, as the second example models, and they run at a time React chooses.
• Forgetting a default branch. The reducer returns undefined for an unknown action and the state disappears. Return state, or throw to catch typos early.

What interviewers ask

• When would you choose useReducer over useState? — When updates to several related fields happen together or follow non-trivial rules; the reducer is a pure function that can be tested in isolation.
• Why must a reducer be pure? — React may call it more than once (Strict Mode does so on purpose) and only keeps one result; purity makes repeated calls harmless and the state predictable.