❯ State Management & Data Fetching

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

Where state lives: lift it, then stop

The opening question in most loops: two sibling components need the same data. The answer is lifting state — move it to the closest common parent, pass it down as props, pass changes back up as callbacks. The trap: reaching for Context or a store the moment prop-passing feels tedious. The react.dev ordering is explicit: pass props first; if intermediate layers only forward data, extract components and pass JSX as children instead; only when both fail, consider Context.

Context and its blast radius

Context fits low-frequency, wide-reach values — theming, the current user, routing, reducer-backed app state. It fails as a general store because of the re-render blast radius:

• When a provider’s value changes (compared by Object.is), React re-renders every consumer beneath it.
• Wrapping a consumer in memo does not help — memoized children still receive fresh context values.
• An inline object literal as the provider value mints a new reference every render — memoize it with useMemo and useCallback.

Context plus useReducer is the sanctioned scaling step: the reducer centralizes transitions, one provider carries state, a second carries dispatch — which is referentially stable, so components that only trigger updates never re-render on state changes. Two React 19 notes: render <ThemeContext value> directly (no .Provider), and use(ThemeContext) works inside conditionals, unlike useContext.

External stores: Redux Toolkit and Zustand

Redux Toolkit’s createSlice generates action creators and action types from your case reducers; inside them you write “mutating” code safely because Immer tracks draft mutations and emits immutable updates. RTK earns its weight when many features share state and you want middleware, devtools time travel, or a serializable action log — not for a modal flag and a form.

Zustand inverts the model: the store lives outside the component tree, create returns a hook, and components subscribe through selectors — useStore((s) => s.count) — re-rendering only when the selected slice changes. No provider, minimal boilerplate. Selector-based subscription is the direct answer to the blast-radius problem above.

Server state is not client state

Server data is a cache of someone else’s truth: async, shared, stale the moment it arrives. Copying fetch results into Redux or useState hand-rolls caching, dedupe, and invalidation — the trap answer. TanStack Query owns that lifecycle around a query key and a fetch function:

• staleTime defaults to zero — cached data is stale immediately, and stale queries refetch in the background on mount, window refocus, and network reconnect; raise it to declare how long data stays fresh.
• gcTime (default five minutes) controls when inactive cache entries are garbage-collected.
• Failed queries retry 3 times with exponential backoff before surfacing an error.
• After a mutation, invalidateQueries with a key prefix marks matching queries stale and refetches the active ones.

Name the model: stale-while-revalidate — render cached data instantly, update it quietly.

Derived state, forms, and the URL

The highest-frequency trap: state you can compute. If a value derives from existing props or state, calculate it during render — never mirror it into state via an effect:

// redundant: extra render pass, sync bugs
const [fullName, setFullName] = useState('');
useEffect(() => { setFullName(first + ' ' + last); }, [first, last]);

// derive it during render instead
const fullName = first + ' ' + last;

Expensive derivations get useMemo, not state plus an effect; resetting a subtree when an identity changes is a key change, not a sync effect.

Forms: controlled inputs (value plus onChange) when the UI reacts per keystroke; uncontrolled inputs read at submit when it does not. Form libraries win here by subscribing to individual fields, avoiding whole-form re-renders on every keystroke.

URL as state is the differentiator answer: filters, pagination, tabs, and selected items belong in search params — shareable, bookmarkable, refresh-proof, with back-button behavior for free. Rule of thumb: if a user might share a link to the view, the state belongs in the URL.