❯ Hooks & Lifecycle

Roughly 25% of a typical loop — and 25% of the mock exam here.

useState and useReducer

Interviewers open with state because the traps are cheap to set. Calling the setter with a plain value uses whatever the closure captured, so setCount(count + 1) twice in one handler adds one, not two. The functional updater setCount(c => c + 1) reads the pending state instead — that is the rule that resolves every “why did it only increment once” question. Lazy initialization, useState(() => expensive()), runs the initializer once on mount; passing expensive() directly runs it on every render even though the result is discarded.

useReducer is the answer when the next state depends on structured transitions: the reducer is pure and testable without rendering, and dispatch has a stable identity, so it drops out of dependency arrays.

useEffect: dependencies, cleanup, timing

Dependencies are compared with Object.is:

• No array: the effect runs after every commit.
• Empty array: once after mount (plus a deliberate setup, cleanup, setup cycle in dev Strict Mode — a bug surfaced there is a real cleanup bug).
• Listed deps: after mount, then after any commit where a dep changed. Cleanup runs before each re-run with the old values, and once more on unmount.

Timing is the discriminator interviewers want. useEffect fires after the browser paints; useLayoutEffect fires after DOM mutation but before paint, blocking it. Default to useEffect; reach for useLayoutEffect only to measure or position DOM and kill visible flicker. For data that lives outside React — a store singleton, navigator.onLine — useSyncExternalStore(subscribe, getSnapshot) replaces the effect-plus-setState pattern: it avoids tearing during concurrent renders, and getSnapshot must return a cached, immutable snapshot, not a fresh object per call.

useCallback, useMemo, and stale closures

Both cache across renders by dependency comparison; useCallback(fn, deps) is exactly useMemo(() => fn, deps). Their real job is referential equality: a child wrapped in memo re-renders anyway if you hand it a fresh object or callback each render. They are performance tools only — correctness must never depend on them — and react.dev notes the React Compiler now auto-memoizes, shrinking how often you write either by hand.

The stale closure is the signature trap: an effect with [] captures the first render’s values forever.

useEffect(() => {
  const id = setInterval(() => setCount(count + 1), 1000); // always 0 + 1
  return () => clearInterval(id);
}, []); // count is stale — use setCount(c => c + 1) or list the dep

useRef, useContext, useId

Mutating ref.current never triggers a re-render, which makes refs the home for values that must survive renders without driving them: timer ids, previous props, DOM nodes. Never read or write a ref during render. For DOM access, pass the ref to a JSX ref attribute and React fills in the node after commit. Since React 19, function components receive ref as an ordinary prop — forwardRef is no longer needed and is slated for deprecation — and a ref callback may return a cleanup function that React calls on unmount.

useContext(SomeContext) reads the nearest provider’s value; every consumer re-renders when that value changes identity, so memoize the object you pass down. React 19 also lets you render SomeContext itself as the provider. useId generates hydration-safe unique ids for accessibility wiring like aria-describedby — never for list keys, which must come from your data.

Rules of hooks and custom hooks

Hooks are called unconditionally, at the top level of a component or custom hook. The why is the interview answer: React stores hook state by call order, so a hook behind an if shifts every later slot and corrupts state. Custom hooks are plain functions named useX that call other hooks — they share stateful logic, not state. Two components calling the same custom hook get fully independent state, a distinction interviewers probe deliberately.