useReducer

The plain-language idea

useReducer(reducer, initialState) gives you [state, dispatch]. Instead of calling many separate setters, you dispatch a plain object describing what happened, and one function — the reducer — decides what the new state should be.

function reducer(state, action) {
  switch (action.type) {
    case "increment": return { count: state.count + 1 };
    case "decrement": return { count: state.count - 1 };
    case "reset": return { count: 0 };
    default: throw new Error(`Unknown action: ${action.type}`);
  }
}

function Counter() {
  const [state, dispatch] = useReducer(reducer, { count: 0 });
  return (
    <button onClick={() => dispatch({ type: "increment" })}>{state.count}</button>
  );
}

Notice the shape: (accumulator, item) => newAccumulator from the JavaScript track's reduce is exactly (state, action) => newState here. dispatch({ type: "increment" }) is one item in a stream of actions; the reducer is the step function; state is the running accumulator. useReducer is reduce, running over time instead of over an array.

dispatch({ type: 'increment' }) sends an action — a plain object describing what happened.

BackNext

What people usually miss

Watch out

• The reducer must be pure. No mutating state directly, no side effects (fetching, logging) inside it — same rule as reduce's step function, for the same reason: React may call it more than once (Strict Mode) or discard a call, and impurity breaks that.
• dispatch's identity is stable across renders (React guarantees this), unlike a plain function you'd define inline — this makes it safe to pass down to deeply nested children without triggering React.memo to think it changed.
• useReducer and useState aren't different mechanisms — useState is actually implemented in terms of the same primitive useReducer is; picking one is a code-organization choice, not a performance one.

Why this matters in interviews

"When would you reach for useReducer over useState?" checks whether you can identify the "state transition" shape in real UI logic — and connecting it explicitly back to reduce is a strong signal you see the underlying pattern, not just two separate APIs to memorize.