Welcome to Intermediate. Every piece of changing data covered so far has gone through useState, specifically because changing it needed to update the screen. Not everything fits that description — sometimes a value just needs to persist between renders without ever causing one, or a component needs to reach directly into the actual DOM node React rendered. useRef is the hook for both of those cases.

Accessing a Real DOM Node

useRef(null) creates a ref object with a single property, current, starting at null. Passing it to an element's special ref attribute tells React to set inputRef.current to that exact DOM node once it's rendered — from then on, inputRef.current is the real <input> element, with every normal DOM method (.focus(), .scrollIntoView(), reading .offsetHeight, and so on) available on it directly.

The Key Difference from useState

Updating renderCount.current directly — no setter function, just a plain assignment — works perfectly well, and the new value is there on the next render. What it doesn't do is cause a re-render. If nothing else in this component ever updates, the displayed count would only ever change because something else (a parent re-rendering it, for instance) triggers a new render for a different reason. This is the core distinction from useState: a ref update is invisible to React's rendering system entirely.

Storing a Mutable Value Across Renders

Fundamentals Chapter 8's clock example stored its interval id as a plain variable inside the effect, cleaned up automatically when the effect re-ran. Here, the interval needs to be started and stopped from two separate event handlers — handleStart and handleStop — rather than a single effect's cleanup, so the id needs to survive between renders without living inside any one function call. A ref is exactly built for that: a box that keeps holding its value across every re-render, completely independent of the render cycle itself.

Coding Challenges

The shopping cart project briefly used Context to solve a real problem: a header badge, a product grid, and a cart page all needing the same data despite sitting nowhere near each other in the component tree. This chapter covers that mechanism properly — Context as React's built-in answer to the prop-drilling problem first raised back in Fundamentals Chapter 10.

The Three Pieces

createContext(null) creates the context object itself, separately from any actual data — the null is just a fallback default. <ThemeContext.Provider value={...}> makes that value available to everything nested inside it; ThemeButton can sit any number of components below App — even with several unrelated components in between — and still reach the same theme/setTheme directly via useContext(ThemeContext), without a single one of those in-between components ever mentioning theme at all.

Providing State and Functions Together

The shopping cart project's pattern — bundling state and the functions that update it into one object passed to value — is the standard shape for a real context, not just a single raw value. It's common enough to extract the whole thing into its own dedicated "provider" component, exactly as CartProvider did:

ThemeProvider wraps {children} (the composition pattern from Fundamentals Chapter 9) rather than rendering anything visible itself — its entire job is owning the state and exposing it, leaving every consumer free to use it however it wants.

A Custom Hook for Cleaner Consumption

Wrapping useContext(ThemeContext) in a small custom hook is an extremely common pattern in real codebases — it means every consumer imports one clearly-named function (useTheme) instead of needing to know the underlying context object exists at all. Custom hooks get their own full treatment next chapter; this is a first glimpse of how naturally they pair with Context specifically.

Coding Challenges

The Kanban board and shopping cart projects both had state that could change in several distinct ways — add, remove, update quantity, move between columns — each handled by its own separate function calling setItems or setColumns with slightly different logic. As the number of "ways state can change" grows, that logic ends up scattered across many handlers. useReducer centralizes all of it into one place: a single function describing every possible state transition.

A Reducer Is Just a Function

A reducer takes the current state and an action describing what happened, and returns the new state — nothing more. It's a plain function, with no React-specific code inside it at all; every possible transition lives in one readable place instead of being spread across separate handleIncrement/handleDecrement/handleReset functions.

useReducer in a Component

useReducer(reducer, initialState) returns [state, dispatch] — state is read exactly like useState's value, but instead of a setter, dispatch sends an action object to the reducer, which decides what the new state should be. No button handler needs to know how to update the count — each one just describes what happened ("increment"), leaving the actual logic entirely inside the reducer.

Actions with a Payload

payload is just a convention — a place to attach whatever extra information a particular action needs (which todo's id to toggle or remove, the text for a new one). Project 1's todo list scattered this same add/toggle/remove logic across three separate state-updating functions; written as a reducer, all three transitions live together, each one still using the same immutable-update rules (spread, .map(), .filter()) from Fundamentals Chapter 3 and Project 1 — just consolidated into a single function instead of three.

Pairing useReducer with Context

useReducer and Context combine naturally for global state: the reducer's state becomes the context's value, and dispatch itself can be exposed through context too, letting any deeply nested component dispatch an action without ever needing the state-updating logic passed down to it as props. This combination is genuinely how some real apps implement global state without reaching for an external library at all — a more powerful version of the CartProvider pattern from Project 6, with one centralized reducer instead of several separate updater functions.

Coding Challenges

Chapter 2's useTheme was already a custom hook, introduced without dwelling on the concept itself. A custom hook is nothing more than a regular JavaScript function whose name starts with use, which calls other hooks inside it — there's no special syntax, no registration step, no library involved. It exists purely to pull repeated stateful logic (state plus the behavior around it) out of components and into something reusable, the same way a regular function extracts repeated non-stateful logic.

The Simplest Possible Custom Hook

useToggle wraps a useState call and the boolean-flip logic that goes with it (the same pattern as Fundamentals Chapter 3's LightSwitch), so any component needing toggle behavior can call one hook instead of writing the flip function itself every time. It returns a tuple, like useState does, purely as a convention — a custom hook can return anything at all (an object, a single value, several values).

useLocalStorage — Syncing State with the Browser

This is exactly the load/save pair Project 3's stretch goals suggested extracting — two effects' worth of localStorage logic, now living in one hook instead of being duplicated in every component that needs persistence. Passing a function to useState (rather than a plain value) is worth noting here: that initializer function only runs once, on the very first render, rather than re-reading localStorage on every single re-render.

useDebounce — Delaying a Fast-Changing Value

This is the Book Search project's debounce logic, lifted out of a component and into a reusable hook — exactly the stretch goal it suggested. useDebounce takes a fast-changing value (query, updated on every keystroke) and returns a second value that only catches up after delay milliseconds of no further changes, using the same setTimeout + cleanup pattern from Fundamentals Chapter 8 and Project 4, just packaged for reuse anywhere a debounced value is needed.

Coding Challenges

Project 4 used four pieces of React Router with a quick primer to get a search page and a detail page working. This chapter covers routing properly — including the two pieces that primer left out entirely: programmatic navigation, and sharing a layout (like a persistent sidebar or header) across several routes.

The Setup, Recapped

BrowserRouter wraps the whole app once, near the top. Routes looks through its Route children for the one whose path matches the current URL, and renders only that one's element.

Link vs NavLink

Both navigate without a full page reload, exactly like Project 4's Link. NavLink is specifically for navigation menus — it knows whether its own to matches the current URL, and exposes that as isActive inside a function passed to className (or style), making "highlight the current page in the nav" straightforward without manually comparing the URL yourself.

useParams and useNavigate

useParams() was already used in Project 4 to read a dynamic URL segment (/product/:id → { id }). useNavigate() is new here — it returns a function for navigating programmatically, from inside an event handler or effect, rather than from a Link the user clicks. This is the right tool for redirecting after a form submits, after a delete completes, or after a login succeeds.

Nested Routes and a Shared Layout

Nesting Route elements means the parent's element (DashboardLayout, with its sidebar) renders for every URL starting with /dashboard, while <Outlet /> marks exactly where the matching child route's content should appear inside it. Visiting /dashboard/profile renders DashboardLayout with ProfilePage dropped into the Outlet — the sidebar never unmounts or re-renders just because the inner page changed, which is exactly the composition pattern (children/Outlet as a flexible slot) from Fundamentals Chapter 9, applied to routing.

A Catch-All "Not Found" Route

A Route with path="*", placed last among the route definitions, matches any URL that didn't match an earlier, more specific route — the standard way to show a friendly 404 page instead of a blank screen for a mistyped or stale URL.

Coding Challenges

Fundamentals Chapter 8 introduced fetching with a minimal example; the Weather App project formalized it into a single status value (idle/loading/error/success); the Book Search project flagged, but didn't fix, a real correctness problem — a slow, stale request finishing after a newer one and overwriting it with outdated data. This chapter closes that gap properly, and ends with the same fetch logic extracted into a reusable hook.

Async Inside useEffect — The Right Shape

The function passed directly to useEffect can never be async itself — React expects that function to return either nothing or a cleanup function, and an async function always returns a Promise instead, which React would mistake for a cleanup function and try to call later. The fix is always the same: define a separate async function inside the effect, and call it immediately.

Proper Error Handling

A crucial detail easy to miss: fetch only rejects (triggering catch) on a genuine network failure — a 404 or a 500 response is still a "successful" fetch as far as the Promise is concerned. response.ok is what actually distinguishes a real HTTP success (status 200–299) from an error status, which is why it needs to be checked and thrown manually to land in the same catch block as a true network error.

The Race Condition, Properly Fixed

This is the fix Project 4 flagged but didn't implement. When url changes before the previous fetch finishes, React runs the cleanup function (from Fundamentals Chapter 8) for the old effect before starting the new one — setting that old effect's own ignore flag to true. When the old, now-stale response finally arrives, if (!ignore) is false, and its outdated data is correctly discarded rather than overwriting the newer request's result.

Extracting useFetch

Everything in this chapter — loading state, error handling, race-condition protection — now lives in exactly one place, exactly the custom-hook extraction principle from Chapter 4. Every component that needs to fetch something calls useFetch(url) and gets correct behavior automatically, instead of re-implementing this same logic (and re-introducing the same bugs) in every single component that fetches data.

Coding Challenges

Chapter 2 warned that every consumer of a context re-renders whenever its value changes — and left that as a tradeoff to accept for rarely-changing state. This chapter gives the actual tools for reducing unnecessary re-rendering generally, closing with the fix for that exact warning.

React.memo — Skipping a Component's Re-render

Without memo, clicking the button re-renders App — and by default, every child re-renders right along with its parent, regardless of whether that child's own props actually changed. memo(ExpensiveList) wraps the component so React first compares its new props against the previous render's props; if they're the same, React skips re-rendering it entirely, reusing the previous output instead.

useMemo — Memoizing a Value

useMemo(calculateValue, dependencies) only re-runs calculateValue when something in dependencies has actually changed since the last render — with an empty array, the array of fruit strings is computed exactly once and the same array reference is reused on every subsequent render. Now ExpensiveList's memo comparison sees the identical items reference each time count changes, and correctly skips re-rendering.

useCallback — Memoizing a Function

A regular function defined inside a component (onSelect={(item) => ...} written inline, or even a named function declared in the component body) is also a new value every render — functions are compared by reference too, the same as arrays and objects. useCallback(fn, dependencies) is useMemo's counterpart specifically for functions: it returns the exact same function reference across renders as long as the dependencies haven't changed, which is what lets a memoized child receiving that function as a prop actually skip re-rendering.

Fixing the Context Re-render Warning from Chapter 2

Chapter 2's { theme, toggleTheme } object literal, written directly inside value={{ ... }}, was a brand-new object every time ThemeProvider rendered for any reason — even one completely unrelated to theme — forcing every consumer to re-render along with it. Wrapping it in useMemo means value only becomes a genuinely new object when theme itself actually changes, exactly addressing the warning raised back then.

Coding Challenges