Topic

Extracting state logic into a reducer

Definition

A reducer is a pure function that derives the next state from the current state and an action describing an event.

In simpler words

Move many related state updates into one named function so handlers only describe what happened.

useReducer, actions, and pure transition logic.

Open official example (opens in new tab)

After this you can

Organize complex local state without hiding transitions.
Explain the trade-off to a teammate using a small example.
Name at least one common bug pattern for this topic.

Understand Extracting state logic into a reducer

useReducer, actions, and pure transition logic.

Start by identifying which value or browser behavior changes. Then describe the UI from that current input instead of editing the DOM as a separate source of truth.

Extracting state logic into a reducer in code

function reducer(state, action) {
  if (action.type === "added") return [...state, action.ticket];
  return state;
}

Read the example from data and control flow to the resulting UI. Keep the component boundary small.

Apply Extracting state logic into a reducer

Keep rendering as a calculation. Put user-triggered changes in event handlers, preserve UI memory in state, and reserve external synchronization for Effects or the server-state layer.

Name values by their UI meaning, test the loading and error path when data is remote, and avoid keeping two editable copies of the same value.

Ask before adding code: is this local UI memory, shared client state, or Nest-owned server state?

Where bugs hide

Definition

High-bug areas are places where a small API misuse looks correct but produces stale UI, duplicate work, or silent failures.

In simpler words

Each mistake below shows Wrong vs Right code — compare them side by side.

When something misbehaves, match the symptom to a pattern below before rewriting the feature.

Prefer fixing the ownership or update path over adding another Effect or sync step.

Mistake: Mutate in reducer (no Immer)

// Wrong
function reducer(state, action) {
  state.items.push(action.item);
  return state;
}

// Right
function reducer(state, action) {
  return { ...state, items: [...state.items, action.item] };
}

Return new state (unless you intentionally use Immer).

Mistake: Async Nest call inside reducer

// Wrong
function reducer(state, action) {
  ticketsApi.create(action.dto);
  return state;
}

// Right
// dispatch from handler after await mutation
dispatch({ type: "added", ticket });

Reducers stay pure; side effects live in handlers/Effects.

Mistake: Reducer for one boolean

// Wrong
useReducer(toggleReducer, false)

// Right
const [on, setOn] = useState(false);

useState is enough for simple toggles.

Live playground

Extracting state logic into a reducer sandbox

Change one input at a time and predict the next render.

count = 0

dispatch({ type: "inc" })

Keep in mind

Keep the formal definition in mind; it explains which tool belongs where.
Prefer one source of truth over synchronized copies of the same value.
When behavior surprises you, trace: input → update → render → committed UI.
Study the Wrong vs Right examples in “Where bugs hide” before you merge.

Test

Check your understanding

At least 10 questions — mix of concept, syntax, practical, and logic. Score ≥80% (enforced by the API) to save progress.

Checking your session…

15 questions · concept 5 · syntax 3 · practical 4 · logic 3

1. What does useReducer help with?

Concept

Run asynchronous side effects in a single placeAutomatically persist state to the server on each actionEliminate the need for a component to re-renderCentralize complex state transitions in a reducer function

2. Reducer signature?

Syntax

(state, action) => fetch(...)(state, action) => mutate state in place(state, action) => nextState — pure(state) => void

3. Dispatch purpose?

Practical

Compute the next state and return it to the callerRun the reducer and re-subscribe all consumersDirectly assign the new value into the state variableSend an action describing what happened

4. When prefer reducer over many useStates?

Logic

Whenever a component has more than one useStateOnly when the state is a single boolean toggleRelated updates / complex transitions / clearer action logWhenever you need to fetch data on mount

5. Action shape habit?

Concept

{ payload: ... } with no type field{ type: 'added', payload: ... }A function that returns the next stateThe next state object itself, with no type

6. Why purity in reducers?

Practical

Because impure reducers cannot be registered with useReducerSame state+action ⇒ same next state; enables predictabilitySo the reducer can safely mutate and return the same objectBecause React runs reducers on a background thread

7. useReducer initial state?

Syntax

Passed as the first argument before the reducerReturned from the reducer on the first renderSecond arg initialState or lazy init third formSet by dispatching an init action after mount

8. Switch default branch?

Logic

Return state unchanged or throw for unknown actionsReturn undefined for any unhandled action typeReturn the initial state for unknown actionsRe-dispatch the action to try the next case

9. Can reducers update multiple fields?

Concept

No — dispatch one action per field to updateOnly if you mutate each field on the draft directlyYes — return a new state object with all needed changesOnly when the fields live in separate reducers

10. Which is wrong?

Practical

Returning a brand-new state object from each caseSwitching on action.type to pick the transitionMutating state inside the reducer and returning itCalling dispatch from event handlers

11. Why return a new array instead of state.push(item)?

Conceptintermediate

function reducer(state, action) {
  switch (action.type) {
    case 'added':
      return [...state, action.item];
  }
}

push is faster so it is preferredArrays cannot be spread in reducersMutation triggers desirable extra rendersReducers must be pure and return new state, not mutate the old

12. What bug appears for unknown action types?

Syntaxadvanced

function reducer(state, action) {
  switch (action.type) {
    case 'inc': return { n: state.n + 1 };
  }
}

It throws automaticallyIt re-runs the last caseNothing — React handles itIt returns undefined, wiping state; add a default that returns state

13. What is this line doing?

Practicalintermediate

dispatch({ type: 'added', item });

Directly mutating stateSending an action describing what happened to the reducerCalling NestRendering the component

14. What is wrong with this reducer?

Logicadvanced

function reducer(state, action) {
  if (action.type === 'load') {
    return fetch('/api').then(r => r.json());
  }
}

Reducers must be synchronous and pure; do fetching in an event or Effectfetch must use axiosThe reducer needs the async keywordNothing — reducers can be async

15. Can one action update multiple fields at once?

Conceptintermediate

case 'submit':
  return { ...state, status: 'sent', error: null };

No — one field per actionYes — return a new object spreading state with all the changesOnly with ImmerOnly in Redux Toolkit

Checking your session…