Context plus useReducer — used in the Shopping Cart project and formalized in Intermediate Chapters 2–3 — genuinely works for global state, and Chapter 7's useMemo fix solved its biggest re-render problem. It still has real limits at scale: every piece of global state generally needs its own Provider wrapping the app, and even with memoization, splitting state cleanly across many unrelated concerns gets unwieldy. Zustand and Redux Toolkit are the two most common dedicated answers to that — different philosophies, both still built around the same core idea: state living outside any one component, with components subscribing to the pieces they need.

Zustand — Minimal Global State

create() builds a store and a hook for reading it, in one step — the store itself lives entirely outside the React component tree, so there's no <Provider> wrapping anything, unlike every Context example so far. Each call to useCounterStore(selector) subscribes only to the specific piece of state that selector returns — Counter only re-renders when count itself changes, not when some unrelated piece of the same store changes, solving Context's all-or-nothing re-render problem directly rather than needing the useMemo workaround from Chapter 7.

Rebuilding the Shopping Cart with Zustand

The duplicate-entry-check logic from Project 6's addToCart is identical here — Zustand changes where state lives and how components subscribe to it, not the immutable-update rules underneath. Any component anywhere can call useCartStore((s) => s.items) or useCartStore((s) => s.addToCart) directly — no CartProvider wrapping the app, no useContext call.

Redux Toolkit — More Structure, More Ceremony

Redux Toolkit follows the same dispatch/action/reducer shape as useReducer from Intermediate Chapter 3, scaled up with "slices" for organizing many pieces of state, a single combined store, and (unlike a hand-written reducer) the ability to write code that looks like direct mutation inside a reducer safely — Redux Toolkit uses a library called Immer underneath to translate that into a proper immutable update automatically. It does still need a <Provider> wrapping the app, much like Context.

Coding Challenges

Intermediate Chapter 6 built a useFetch hook by hand: loading/error state, a manual response.ok check, and an ignore-flag to fix a genuine race condition. Project 7's dashboard used React Query's useQuery informally to skip writing all of that. This chapter explains exactly what it's doing underneath, and goes further — caching, automatic refetching, and updating server data with useMutation.

Setup, Recapped

One QueryClient, wrapping the app once — the same Provider shape seen with Context and Redux Toolkit, holding a cache shared by every useQuery call anywhere below it.

How queryKey Solves Chapter 6's Race Condition — Automatically

Including id directly inside queryKey — ["product", id] — means React Query treats every distinct id as a separate cache entry. Switching rapidly between two ids no longer risks the stale-overwrite bug from Chapter 6's challenge: each id's request and result are tracked independently by key, so a slow response for an old id can never land on top of a newer id's already-displayed data. No ignore flag, no AbortController, written by hand at all — the keying scheme itself prevents the problem from Chapter 6 entirely.

Caching in Practice

The first component to call useQuery({ queryKey: ["product", 5], ... }) triggers the actual fetch; if a second, completely unrelated component requests the exact same key later, React Query returns the already-cached result instantly, without firing a second network request at all — this is what made Project 7's badge-plus-detail-page style dashboard so much simpler than hand-rolling the same sharing logic with useFetch.

staleTime controls how long cached data is considered "still good enough" before React Query will bother refetching it on the next render of a component using that key; refetchInterval (used informally in Project 7) is for actively polling data that changes on its own over time, like live prices.

useMutation — Changing Server Data

useQuery is for reading server data; useMutation is for changing it — a POST/PUT/DELETE request triggered by calling mutation.mutate(...), typically from an event handler rather than automatically on render. onSuccess's call to queryClient.invalidateQueries({ queryKey: ["todos"] }) tells React Query that any cached data under that key is now out of date, triggering every component reading ["todos"] to refetch automatically — the standard way a mutation keeps the rest of the UI in sync with what just changed on the server.

Coding Challenges

Every component built so far has been bundled into the app's JavaScript from the very first page load, regardless of whether it's ever used in a given visit. As an app grows — more pages, more rarely-used features, larger third-party libraries (a charting library, a rich text editor) — that single bundle keeps growing too, even for a user who only ever visits one page. Code splitting breaks the bundle into smaller pieces, loaded on demand; Suspense is what shows something reasonable on screen while a piece is still being fetched.

React.lazy — Loading a Component on Demand

lazy(() => import("./SettingsPage")) doesn't load SettingsPage's code at all until the moment it's actually about to be rendered for the first time — the dynamic import() call kicks off a separate network request for just that component's code, fetched as its own small bundle ("chunk") rather than being part of the main one. While that chunk is loading, the nearest wrapping <Suspense fallback={...}> shows its fallback instead of the real component, swapping over automatically the instant loading finishes.

Route-Based Splitting — The Most Common Use Case

Pairing lazy with the routes from Intermediate Chapter 5 is the single most common pattern: a user visiting / only ever downloads HomePage's code, SettingsPage's chunk never loads at all unless that user actually navigates to /settings. One Suspense boundary wrapping the whole Routes block is usually enough — every route shares the same fallback while its own page's chunk loads.

Loading a Rarely-Used Feature on Click

Here, AnalyticsChart's code (likely a sizeable charting library) doesn't load on the initial page visit at all — only once showChart becomes true, the conditional rendering from Fundamentals Chapter 5 means React only tries to render <AnalyticsChart /> (triggering its chunk to load) at the exact moment a user actually wants it.

Nesting Suspense Boundaries

A single component can be wrapped in its own dedicated Suspense, separate from a larger one further up — useful when one part of a page should show its own specific loading state rather than blocking everything else on the page behind one shared fallback. There's a real tradeoff either way: fewer, broader boundaries mean simpler fallback UI but more of the page "waits together"; more, narrower boundaries let unrelated parts of a page appear independently, at the cost of more fallback states to design.

Coding Challenges

Every project so far has been verified by hand — running the app and clicking around to confirm something works. That's fine for small projects, but doesn't scale, and gives nothing to catch a regression introduced weeks later by an unrelated change. React Testing Library (paired with a test runner — Jest, or Vite's own Vitest) lets that same kind of verification be written once and run automatically.

The Core Philosophy

React Testing Library is built around one guiding rule: test what a user actually sees and does, not a component's internal implementation. That means querying for visible text, labels, and accessible roles — never reaching into a component's state, props, or internal function calls directly. A test written this way keeps passing through a refactor that changes how a component works internally, as long as it still behaves the same way from the outside — exactly the kind of test that's actually worth having.

A First Test

render(<Greeting name="Philip" />) renders the component into a virtual DOM the test can inspect; screen.getByText(...) searches that rendered output for matching text, throwing immediately if nothing matches; expect(...).toBeInTheDocument() is the actual assertion — confirming the element was actually found.

Simulating User Interaction

userEvent simulates real user interaction more faithfully than directly firing a raw DOM event — clicking, typing, and focusing all go through the same library, recommended over the lower-level fireEvent for exactly that reason. getByRole("button", { name: "+1" }) finds the button by its accessible role and visible label — the same way a screen reader or a person scanning the page would identify it, rather than relying on a CSS class or test-specific attribute.

Testing a Form

vi.fn() (or jest.fn()) creates a mock function — a fake function the test can pass in as a prop and later inspect, asking "was this called, and with what?" without needing a real implementation behind it. Passing a mock as onSubmit lets the test confirm SearchForm calls it correctly with the typed value, without needing the component to actually be connected to a real API anywhere.