ReactJS State Management Syllabus

When is `useReducer` preferred over `useState`?

When state logic is complex, involves multiple sub-values, or the next state depends on the previous one via many action types—centralizing transitions in one reducer improves clarity and testability.

What is the signature of a reducer function?

`(state, action) => newState`. It takes the current state and an action, and returns the new state.

What key rule must a reducer function obey regarding purity?

A reducer must be a pure function: no side effects, no mutation of arguments, and it must return a new state object based solely on `state` and `action`.

What is an 'action' in the `useReducer` pattern?

A plain object describing what happened, conventionally with a `type` field and optional `payload`, e.g. `{ type: 'increment', payload: 5 }`.

How do you trigger a state change with `useReducer`?

Call `dispatch(action)`, e.g. `dispatch({ type: 'increment' })`. React runs the reducer with the current state and the action to compute the next state.

What are the arguments of `useReducer(reducer, initialArg, init)`?

`reducer` (the `(state, action) => newState` function), `initialArg` (initial state or seed), and an optional `init` function for lazy initialization computed as `init(initialArg)`.

Why use the optional `init` (third) argument of `useReducer`?

For lazy initialization: the initial state is computed by `init(initialArg)` only on the first render, and it also enables resetting state (e.g. in response to an action).

Show a typical reducer handling multiple action types.

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

Why is a `switch` statement commonly used inside a reducer?

To branch on `action.type` and return the appropriate next state for each action, keeping all transition logic in one readable place.

In a reducer, why do you return `{ ...state, field: newValue }` instead of mutating `state`?

To preserve immutability: returning a new object lets React detect the change by reference and keeps the reducer pure and predictable.

Compare `useState` and `useReducer` at a high level.

`useState` is simpler for independent/simple state; `useReducer` centralizes complex transition logic, is easier to test, and is preferable when many actions update related state.

Does `dispatch` from `useReducer` have a stable identity across re-renders?

Yes. React guarantees the `dispatch` function identity is stable, so it can be safely omitted from effect/callback dependency arrays and passed down without causing re-renders.

What problem does the Context API solve?

It avoids 'prop drilling' by letting you share data (theme, auth, locale, etc.) across the component tree without manually passing props through every intermediate level.

How do you create a Context?

Call `const MyContext = React.createContext(defaultValue)`, which returns a Context object containing a `Provider` (and, historically, a `Consumer`).

What is the purpose of the `defaultValue` argument in `createContext(defaultValue)`?

It is the value received by consumers only when there is no matching Provider above them in the tree. It is not used when a Provider is present.

How do you provide a context value to a subtree?

Wrap the subtree in the Provider and set its `value` prop: `<MyContext.Provider value={data}>{children}</MyContext.Provider>`.

How do you consume a context value in a function component (modern way)?

Call the `useContext` Hook: `const value = useContext(MyContext)`. It reads the value from the nearest matching Provider above.

What determines which value `useContext` receives?

The `value` prop of the nearest `MyContext.Provider` ancestor in the tree. If none exists, it receives the context's `defaultValue`.

When does a component that calls `useContext` re-render?

Whenever the Provider's `value` changes (compared with `Object.is`), every consumer of that context re-renders.

Why can passing a new object literal as `value` (e.g. `value={{a, b}}`) cause performance issues?

A new object is created every render, so its reference always changes, forcing all consumers to re-render. Memoize it with `useMemo` to keep a stable reference.

How do you combine `useReducer` with Context to build a lightweight global store?

Create the reducer state with `useReducer` at a top-level provider, then pass both `state` and `dispatch` through Context so any descendant can read state and dispatch actions.

What was the older render-prop way to consume context before Hooks?

`<MyContext.Consumer>{value => /* render using value */}</MyContext.Consumer>`, which uses a function-as-child (render prop).

Can a component consume multiple contexts?

Yes. Call `useContext` once per context, e.g. `const theme = useContext(ThemeContext); const user = useContext(UserContext);`.

Can Providers of the same context be nested?

Yes. A consumer reads the value from the nearest Provider ancestor, so inner Providers override outer ones for their subtree.

Why should the argument to `useContext` be the Context object itself, not the Provider?

`useContext(MyContext)` expects the Context object returned by `createContext`; passing `MyContext.Provider` or `.Consumer` is incorrect and will not work.

What is 'lifting state up' in React?

Moving shared state to the closest common ancestor of the components that need it, then passing it down via props so they stay in sync.

How does immutability enable React's efficient change detection?

Because React compares references with `Object.is`, replacing state with a new object/array signals a change in O(1), avoiding deep comparison of contents.

What is the difference between `state` from `useState` and a value from `useContext`?

`useState` state is local and owned by the component; `useContext` reads a value provided by an ancestor Provider and is shared across the subtree.

How can you provide both state and an updater through a single Context cleanly?

Pass an object `value={{ state, dispatch }}` (or `{ value, setValue }`) from the Provider, ideally memoized, so consumers can both read and update shared state.

After calling `dispatch(action)`, is `state` updated immediately in the same function scope?

No. Like `useState`, the update is scheduled; the `state` variable in the current render's closure keeps its old value until the next render.