Lesson 5 · Hooks in depth

More complex state (useReducer)

When to reach for a reducer instead of useState and how to write it cleanly and type-safely.

Before we start: how a bank account works

Imagine a bank worked like this: any member of staff can open your account and overwrite the balance with a number they've worked out themselves. The cashier at the counter, the mobile app, the cash machine, the fee robot – each calculates it slightly differently. Once the balance doesn't add up, nobody can find out why.

A real bank does it differently. Nobody overwrites the balance. Everyone just records what happened: "deposit $500", "card payment $120", "monthly fee". These are called transactions. And the new balance is calculated by one place following fixed rules: add a deposit, subtract a payment, and when there's nothing in the account, decline the payment.

This approach has big advantages:

The rules are in one place. Whoever wants to know how the balance is calculated looks there.
The statement tells a story: you can see exactly which transactions led to today's balance.
The cashier doesn't need to know how to calculate interest. They just record "deposit".

useReducer brings exactly this approach to React. Components don't overwrite state, they just report actions (transactions). The new state is calculated by the reducer – a function with the rules.

1. From "what to set" to "what happened"

We'll start with a task list written the way you know from the lesson on state:

function TaskList() {
  const [tasks, setTasks] = useState<Task[]>([])

  function handleAdd(text: string) {
    setTasks([...tasks, { id: nextId++, text, done: false }])
  }
  function handleToggle(id: number) {
    setTasks(tasks.map((t) => (t.id === id ? { ...t, done: !t.done } : t)))
  }
  function handleDelete(id: number) {
    setTasks(tasks.filter((t) => t.id !== id))
  }
  function handleClearDone() {
    setTasks(tasks.filter((t) => !t.done))
  }
  // …JSX that calls these functions
}

It works. But the rules for how the list changes are scattered across four functions – each "overwrites the balance" in its own way. Once there are twenty of them spread over several components, it's hard to find out who changed what. Let's rewrite it as a reducer in three steps.

Step 1: name what can happen

Each function above corresponds to one event. We'll describe them as actions – ordinary objects with a type property and the data that belongs to the event:

type Action =
  | { type: 'added'; text: string }
  | { type: 'toggled'; id: number }
  | { type: 'deleted'; id: number }
  | { type: 'cleared_done' }

Actions are transactions: "task added, text: Go shopping". They don't say how the array should change – only what happened.

Step 2: write the rules into one function

A reducer gets the current state and an action and returns the new state. All the logic from the four handlers moves here:

function tasksReducer(tasks: Task[], action: Action): Task[] {
  switch (action.type) {
    case 'added':
      return [...tasks, { id: nextId++, text: action.text, done: false }]
    case 'toggled':
      return tasks.map((t) => (t.id === action.id ? { ...t, done: !t.done } : t))
    case 'deleted':
      return tasks.filter((t) => t.id !== action.id)
    case 'cleared_done':
      return tasks.filter((t) => !t.done)
  }
}

Notice that it's an ordinary function, nothing from React. The rules about mutation from the lesson on state still apply – you always return a new array.

Step 3: the component just reports events

function TaskList() {
  const [tasks, dispatch] = useReducer(tasksReducer, [])

  // instead of handleToggle(id):
  <input type="checkbox" onChange={() => dispatch({ type: 'toggled', id: task.id })} />

  // instead of handleAdd(text):
  <form onSubmit={() => dispatch({ type: 'added', text })}>
}

useReducer(tasksReducer, []) is like useState([]), except instead of a setter it returns dispatch – "the counter window where transactions are handed in".
dispatch(action) calculates nothing. It passes the action to React, which calls the reducer.

What happens after ticking a task

The checkbox calls dispatch({ type: "toggled", id: 2 }).
React calls tasksReducer(currentTasks, { type: "toggled", id: 2 }).
The reducer finds the 'toggled' branch and returns a new array in which task 2 has done flipped.
React stores the new array as the state and re-renders the component – just like after a setter.

Demo

Tasks through a reducer + an action log

What you see: The task list from the example. On the right is an action log – "the account statement". Every dispatch is written into it before the reducer processes it.

Try it:

Add the task "Cook lunch". The log shows {"type":"added","text":"Cook lunch"}.
Tick it, then tick "Solve the challenges" too. Two "toggled" actions with different ids appear in the log.
Click Clear finished. One cleared_done action removed several tasks at once – only the reducer knows the rule for "what should be deleted".
Go through the log from the top. From it you could reconstruct exactly what the user did and why the list looks the way it does.

The takeaway: The component just reports what happened. How the state changes is decided by one place – and the action log is a clear story. This is exactly how Redux DevTools work.

Loading the interactive part…

2. useState or useReducer?

Not everything needs a bank. You don't track the change in your own pocket through transactions either – you just know how much is there. It's the same with state: simple, independent values are clearer with useState.

useState (change in your pocket)	useReducer (a bank account)
Simple, independent values (an input’s text, open/closed)	Several values that change together
A few ways to change the state	Many different actions on the same data
You easily calculate the new state in the handler	The new state depends on the previous one in complex ways (validation, transitions)
—	You want to test the logic separately or share it through Context

3. A reducer as a state machine

A washing machine has programmes: ready → washing → spinning → done. It can't be "washing" and "done" at the same time. And while it's washing, the Start button does nothing – there's nowhere to go. Such a device is called a state machine: it has a few clearly named states and rules for moving between them.

Loading data is often written as a set of independent values:

// ❌ Three switches = eight combinations, but only a few make sense
const [isLoading, setIsLoading] = useState(false)
const [error, setError] = useState<string | null>(null)
const [user, setUser] = useState<User | null>(null)
// isLoading && error && user? A washing machine that's washing, done and broken all at once.

As a state machine it looks like this. Every state carries only the data that belongs to it:

type State =
  | { status: 'idle' }                      // ready
  | { status: 'loading' }                   // washing
  | { status: 'success'; user: User }       // done – and only here is there a user
  | { status: 'error'; error: string }      // broken – and only here is there an error

type Action =
  | { type: 'fetch' }
  | { type: 'resolve'; user: User }
  | { type: 'reject'; error: string }

function reducer(state: State, action: Action): State {
  switch (action.type) {
    case 'fetch':
      // A transition rule: while it's already loading, another "Start" changes nothing
      return state.status === 'loading' ? state : { status: 'loading' }
    case 'resolve':
      return { status: 'success', user: action.user }
    case 'reject':
      return { status: 'error', error: action.error }
  }
}

And where's the loading itself? Outside the reducer, in a handler. The reducer only gets the results as actions:

async function load(id: number) {
  dispatch({ type: 'fetch' })                         // washing machine: washing
  try {
    const user = await fetchUser(id)
    dispatch({ type: 'resolve', user })               // washing machine: done
  } catch (e) {
    dispatch({ type: 'reject', error: (e as Error).message }) // washing machine: broken
  }
}

TypeScript then makes sure in the JSX that you can touch state.user only where you've checked state.status === 'success'. A nonsensical combination can't even be written.

Demo

Loading as a state machine

What you see: The reducer from the example above. The card shows content according to the state, below it is the current status. The users load from the fake API with a delay.

Try it:

Click Load a random user. The status goes idle → loading → success and the card shows the name.
Click Load one that doesn't exist. The status goes through loading to error and the card shows the error. The name from before has disappeared – there's no user in the error state.
While loading, the buttons are disabled. If something pressed them anyway, the reducer would ignore the second fetch – like a washing machine that's already washing.
Reset returns the machine to idle.

The takeaway: The state is always in exactly one of four named states and carries only the data that belongs to it. The reducer guards the transitions.

Loading the interactive part…

4. The rules of a reducer

A bank calculates the balance by the rules and does nothing else while doing it – it doesn't call clients or send letters. If it did, every recalculation (during an audit, say) would send another letter. It's the same with a reducer: React can call it several times, and in development mode it does so on purpose.

// ❌ An impure reducer
case 'added':
  saveToServer(action.text)                         // an API call
  return [...tasks, { id: Math.random(), ... }]     // randomness – a different result each time

// ✅ A pure reducer: the same state and action always give the same result
case 'added':
  return [...tasks, { id: action.id, text: action.text, done: false }]
// create the ID in the handler and send it in the action; call the API in the handler or in an effect

A pure function: no API calls, timers, Math.random(), Date.now() or mutations. Whatever is random or asynchronous happens outside and arrives in the reducer in an action.
Actions describe an event, not a setter: 'item_added' is better than 'set_items'. A "deposit 500" transaction, not "set the balance to 1500".
Always return a state – even when the action changes nothing. Returning the same reference means "no change" and React re-renders nothing.
An exhaustiveness check: in the default branch put const x: never = action. When you add a new action and forget to handle it, TypeScript warns you.

How is undo/redo done in a reducer (the Pixel art challenge)?

Instead of one state you remember three things: the past versions, the current version and the "undone" versions for redo:

{ past: [v1, v2], present: v3, future: [] }   // I drew v1 → v2 → v3

// undo: the current one goes to future, the last one from past becomes current
{ past: [v1], present: v2, future: [v3] }

// redo: the other way round
{ past: [v1, v2], present: v3, future: [] }

// a new change (v4): the current one goes to past, future is thrown away
{ past: [v1, v2, v3], present: v4, future: [] }

It only works because you never mutate the state. Every version is a separate array that never changes again, so it's enough to keep them in past. The method array.with(index, value) returns a new array with one element replaced and leaves the old one alone. It's the immutable counterpart of array[index] = value.

Check yourself

Quiz Where does an API call belong when you use useReducer?

In the reducer, in the branch for that actionIn an event handler or an effect – the reducer gets only the result as an actionIn initialStateIn dispatch

Quiz Which action name is better?

{ type: 'set_cart', cart }{ type: 'item_added', productId }

Quiz A form has an input's text and a five-step wizard with validation. What goes where?

Everything into one reducerEverything into useStateThe wizard (steps, data, errors) into a reducer, small UI things can go into useState

Warm-up

Challenge

A light switch

Warm-up

The reducer is missing a single action. Add it and the switch starts working.

Task (the same text is in the comment at the top of the file)

CHALLENGE: A light switch

The reducer already handles the 'off' action. The 'toggle' action is missing.

1. In the reducer, add case 'toggle': return { on: !state.on }

The buttons already send the actions (dispatch).

🧩 Where do the things not defined here come from

CSS classes like row, stack, card, list, btn, input or muted are the course's ready-made styles in src/styles.css (row = side by side, stack = stacked, card = bordered box, muted = grey text).

Loading the interactive part…

I'm done

Challenges

The wizard practises sections 1 and 3: all the transition rules (validation, next/back) belong in the reducer, the component just sends actions. Pixel art adds history: when you have all the changes as actions, undo/redo is surprisingly simple.

Challenge

A multi-step form

Medium Bonus challenge

Step by step like a washing machine: you can't get from step 1 to step 2 until the reducer confirms the details are fine.

🔒 Bonus challenge

Medium and hard challenges are a bonus for signed-in readers. Signing up is free – just an e-mail, no password.

Challenge

Pixel art with Undo/Redo

Hard Bonus challenge

The classic history pattern (past/present/future) used by editors, spreadsheets and Redux-undo. The selected colour isn't in the history – that's change in your pocket.

🔒 Bonus challenge

Medium and hard challenges are a bonus for signed-in readers. Signing up is free – just an e-mail, no password.

Summary

A reducer is a bank account: components report transactions (actions), one place calculates the new state by the rules.
Rewriting from useState: name the events → move the logic into the reducer → replace the handlers with dispatch.
Actions describe what happened, not how to set the state.
A state machine: state as a discriminated union – only valid combinations, the reducer guards the transitions.
A reducer is pure: APIs, randomness and time stay outside and arrive in the reducer in an action.
Combine them: a reducer for domain data, useState for small UI things.

Loading lesson…

💬 Found a mistake, something unclear, or have an idea? Let me know.