What is the difference between `useState` and `useReducer`?

Q: What is the difference between `useState` and `useReducer`?

**Target Audience:** Frontend engineers preparing for React interviews — assumes familiarity with useState . **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: — the exact vocabulary an interviewer expects. Every behavioural claim below was produced by actually running React 19.2.8 in this repo, including the render counts. ## 1. Why This Even Matters — A Story First Imagine a shop with two ways to change the till. In the first, anyone can reach in and set the number to whatever they like. It works fine while there is one number and one person. In the second, nobody touches the till directly — you write down what you *want* ("sale of 3 pounds", "refund", "cash up") and hand the slip to one clerk who applies every change by the same rules. The first is useState . The second is useReducer . The second feels like more ceremony until three people are reac

The problem

Question presented to candidate: "You have a component whose state is getting messy — half a dozen useState calls that keep having to change together. When would you reach for useReducer instead, and what does that actually buy you?"

What a strong answer should cover:

Both add local state to a function component; they are equivalent in power.
useState fits simple, independent values updated directly.
useReducer centralises transitions in a pure reducer (state, action) => newState; components dispatch intent rather than computing the next state.
The real payoff: the reducer is a pure function testable with no React at all, and branchy transitions live in one place.
dispatch has a stable identity across renders, so it can be passed down without breaking React.memo — the same is true of the useState setter.
Multiple dispatches in one handler are batched into a single re-render.
Signal of depth: useState is implemented on the same underlying machinery as useReducer.

Clarifying questions expected:

"Do these state fields have to change together, or are they genuinely independent?"
"Is this state local, or does it need to be shared — in which case is a reducer plus context the right shape?"

Code / implementation expected: Yes — a small reducer with two or three action types, and the dispatch call site.

hooks
state management
useState
useReducer

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Frontend engineers preparing for React interviews — assumes familiarity with useState. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term: — the exact vocabulary an interviewer expects. Every behavioural claim below was produced by actually running React 19.2.8 in this repo, including the render counts.

1. Why This Even Matters — A Story First

Imagine a shop with two ways to change the till. In the first, anyone can reach in and set the number to whatever they like. It works fine while there is one number and one person. In the second, nobody touches the till directly — you write down what you want ("sale of 3 pounds", "refund", "cash up") and hand the slip to one clerk who applies every change by the same rules.

The first is useState. The second is useReducer. The second feel

The solution is hidden so you can try first

6 min read · 9 sections

Try it in the playground

Open any example in the playground to run and change it.

ReactA reducer with a throwing default branch, plus batched dispatches

Open in playground

import { useReducer, useState, memo } from "react";

// Pure — no React, no side effects. This function alone is unit-testable:
//   expect(reducer({ count: 0 }, { type: "inc" })).toEqual({ count: 1 })
function reducer(state, action) {
  switch (action.type) {
    case "inc":   return { count: state.count + 1 };
    case "dec":   return { count: state.count - 1 };
    case "reset": return { count: 0 };
    // Throwing turns a typo in an action type into an immediate, obvious
    // error instead of a silent no-op.
    default: throw new Error("unknown action: " + action.type);
  }
}

// dispatch is referentially stable, so this memoised child never re-renders
// just because the parent did.
const Controls = memo(function Controls({ dispatch }) {
  console.log("Controls rendered");
  return (
    <p>
      <button onClick={() => dispatch({ type: "dec" })}>-</button>{" "}
      <button onClick={() => dispatch({ type: "inc" })}>+</button>{" "}
      <button onClick={() => dispatch({ type: "reset" })}>reset</button>{" "}
      {/* three dispatches, one re-render */}
      <button onClick={() => { dispatch({ type: "inc" }); dispatch({ type: "inc" }); dispatch({ type: "inc" }); }}>
        +3 (batched)
      </button>
    </p>
  );
});

export default function App() {
  const [state, dispatch] = useReducer(reducer, { count: 0 });
  const [unrelated, setUnrelated] = useState(0);

  return (
    <div style={{ padding: 24, fontFamily: "system-ui", lineHeight: 1.6 }}>
      <h3>Count: {state.count}</h3>
      <Controls dispatch={dispatch} />
      <button onClick={() => setUnrelated((n) => n + 1)}>
        Re-render parent ({unrelated})
      </button>
      <p style={{ color: "#666", fontSize: 13 }}>
        Watch the console: clicking the parent button re-renders App, but
        Controls does not re-render — dispatch keeps the same identity.
      </p>
    </div>
  );
}

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.