A reducer describes state transitions; context makes a value available to descendants. Combining them can simplify a screen with several controls, but neither requires moving every piece of application state into one global object.

These React interview questions use a small two-step draft. The goal is to make allowed transitions visible and testable. Context placement comes after deciding which parts of the screen share the draft.

What should the reducer own?

export const initialDraft = { text: '', step: 1 };

export function draftReducer(state, action) {
  switch (action.type) {
    case 'edit':
      return { ...state, text: action.text };
    case 'next':
      return state.text.trim() ? { ...state, step: 2 } : state;
    case 'back':
      return { ...state, step: 1 };
    case 'reset':
      return { ...initialDraft };
    default:
      throw new Error('Unknown draft action');
  }
}

An empty draft cannot move to the review step. Editing returns a new object instead of mutating the old one. Reset returns a fresh initial object. The default case makes an unsupported action visible during development rather than silently concealing a mistake.

How does context fit around this logic?

import { createContext, useReducer } from 'react';
import { draftReducer, initialDraft } from './draftReducer.js';

export const DraftState = createContext(null);
export const DraftDispatch = createContext(null);

export function DraftProvider({ children }) {
  const [state, dispatch] = useReducer(draftReducer, initialDraft);
  return <DraftState.Provider value={state}>
    <DraftDispatch.Provider value={dispatch}>
      {children}
    </DraftDispatch.Provider>
  </DraftState.Provider>;
}

Place this provider around the draft workflow. A separate draft workflow can have another provider with independent state. Components that read the context must handle a missing provider deliberately, usually through a small custom hook that throws a clear developer error.

Why separate state and dispatch?

Some children only need to dispatch an action. Separate contexts avoid making them context consumers of a state object they do not use. This is not a promise that those children can never rerender: parent renders and their own props still matter.

Start with ordinary props when the relationship is simple. Context helps when many descendants need the same value and intermediate components otherwise pass it only for others. It is a distribution mechanism, not a replacement for thoughtful component design.

Where should requests run?

Keep the reducer pure. Do not call a server, write storage or start a timer inside it. An event handler or application action can do that work and dispatch a result action. Define pending, success and failure transitions explicitly if saving becomes part of this workflow.

Do not put a credential or server authorization decision into client state and assume it is secure. The server still checks permissions. A reducer only controls this interface's local transition rules.

Which tests reveal mistakes?

  • Next on an empty string preserves step one.
  • Edit then Next reaches step two with the same text.
  • Back retains text but returns to step one.
  • Reset clears both text and step.
  • The input state remains unchanged after every transition.

These are pure function tests. Add a component interaction test to confirm buttons dispatch the intended actions and labels show the current step. Test the transition rule once rather than repeating its implementation inside many tests.

What would you avoid?

A single provider above the entire application can give unrelated screens a shared lifetime they do not need. Name the owner, scope and reset event first. The strongest answer explains why a reducer improves this workflow and when plain useState would be enough.

References and next practice

react.dev — react context

react question collection · Browse interview topics · Practise a question in Interview Challenge · How to Answer Technical Interview Questions Out Loud