When Local State Isn't Enough

"There are only two hard things in Computer Science: cache invalidation and naming things." — Phil Karlton

For six chapters of this Volume, state has had one home: useState, living inside the component that used it. That got you remarkably far. But every real app eventually hits the same wall — a value that many components, scattered across distant branches of the tree, all need to read and change. The theme. The signed-in user. The shopping cart. A stream of toast notifications. Suddenly useState in one place isn't enough, and the internet is happy to sell you a dozen libraries to fix it. This chapter deliberately reaches for none of them. Before you install a single dependency, the senior skill is knowing what kind of state you actually have — because most of what people cram into a global store doesn't belong there at all. Get the taxonomy right and half your "state management problem" evaporates.

Core Concepts

The progression that got you here — and where it breaks

You already know the arc. Local state with useState handles anything one component owns. When two siblings need the same value, you lift state up to their nearest common parent and pass it down as props — the pattern from Part II. This is the correct default and it scales further than people admit.

It breaks in one specific way: prop drilling. When the component that owns the state and the component that uses it are many levels apart, every layer in between has to accept the prop and pass it along — even components that don't care about it. Those middle components become couriers for data they never read. Change the shape of the value and you edit six files. That is the pain, and it is worth feeling before you medicate it:

Two levels of forwarding is already tedious; imagine ten, in a real tree. This is the problem every state tool claims to solve. But notice the trap: the fix is not "make theme global." The fix is to stop threading it by hand — which Context does without making it "global" in any dangerous sense. We'll build exactly that next chapter. First, the harder question.

Not all state is the same — a taxonomy

The single most valuable idea in this Part: "state" is not one thing. Lumping it together is why so many codebases end up with a bloated global store that's slow to render and impossible to test. Here is the taxonomy that experienced engineers carry in their heads:

Read that last column top to bottom. Four of the five kinds have a home that is not a global store — and they're the four that make up the bulk of a typical app. The amount of true global client state most apps need is astonishingly small. Get everything else into its rightful home and what remains is usually trivial.

Three questions to ask before installing anything

When a value feels like it "needs a store," interrogate it first:

• Is it server state or client state? If the value originates on a server and you're keeping a local copy — a product list, the user's orders, a profile you fetched — it is a cache, and it has all of caching's real problems: staleness, refetching, loading and error status, deduping requests. A general store (Redux, Zustand) gives you none of that; you'd hand-roll it badly. This is server state, and it belongs in React Query / SWR, which we cover later in this Part. Putting server data in a global store is the most common architecture mistake in React.
• Is it truly global, or can it be colocated? "Lots of components use it" often means "lots of components under one subtree use it." Move the state to the top of that subtree, not the top of the app. The closer state lives to where it's used, the smaller its blast radius and the easier it is to delete later.
• How often does it change, and who reads it? A theme that flips twice a session and a cursor position that updates 60 times a second are not the same engineering problem. High-frequency values and widely-read values push you toward different tools (atoms and selectors vs. a single Context). Answer this before choosing, not after your app janks.

The options landscape, at a glance

The rest of this Part details each of these. For now, a map so the categories don't blur together — the mistake is comparing a tool from one row against a tool from another:

The load-bearing insight: that last row is not competing with the others. A healthy app frequently runs React Query for server state and a little Context or Zustand for the handful of global client values. "Redux vs React Query" is a category error — like asking whether you need a fridge or an oven.

The cost of premature global state

Reaching for a global store on day one isn't neutral — it charges rent forever:

• Coupling. State in a shared store can be read and written from anywhere, which sounds like a feature and behaves like a liability. You lose local reasoning — the ability to understand a component by reading only that component. Now any part of the app might be mutating the value you're debugging.
• Re-renders. A naive global value re-renders every consumer on every change. Colocated state re-renders one subtree. The fix is real work (selectors, memoization) that colocated state never needed.
• Testing. A component with local props is trivial to test — pass props, assert output. A component wired into a global store needs the whole store stood up, seeded, and reset between tests. Multiply that across a suite.

Common Mistakes

• Putting server data in a global store. Product lists, user profiles, orders — these are a cache, with staleness and refetch problems a store won't solve. Use a server-state library. This is the number-one mistake.
• Reaching for Redux on day one. Installing heavy global state before you have a global-state problem. Start with useState, lift up, and only escalate when prop drilling genuinely hurts.
• Ignoring the URL as a store. Rebuilding filters, tabs, and pagination in component state when the URL would give you shareable, refresh-proof, back-button-friendly state for free.
• Making everything global "just in case." Global by default destroys local reasoning and balloons your re-render surface. Colocate; promote only what's proven shared.
• Confusing "many components use it" with "it must be global." Often those components share one subtree — lift to that subtree's root, not the app's.
• Choosing a tool before categorizing the state. Picking Zustand vs Redux vs Context before asking whether the value is even client state. Taxonomy first, tool second.

Interview Corner

Chapter Summary

• The progression is useState → lift state up → prop drilling → and drilling is where hand-threaded props break down.
• Fixing prop drilling does not mean making a value global — it means stopping the manual threading.
• "State" is five different things: local UI, form, URL/router, server cache, and global client state. Four of the five don't belong in a global store.
• Ask three questions first: Is it server or client state? Is it truly global or colocatable? How often does it change and who reads it?
• Server data is a cache (staleness, refetch, loading/error) — it belongs in React Query/SWR, never a general store. This is the most common architecture mistake.
• The URL is an underused store: filters, tabs, and pagination there are shareable and survive refresh for free.
• Premature global state charges rent forever: coupling, re-renders, and testing pain. Start local; escalate only when it hurts.

Editorial reflection — the industry spent years arguing about which state library wins, and the answer turned out to be a better question: what kind of state is this? Almost every messy React codebase is messy for the same reason — it treated one hard problem as if it were five different ones, or five different problems as if they were one. The engineers who stay calm as apps grow aren't the ones who memorised Redux. They're the ones who, before installing anything, can look at a value and say exactly where it belongs — and, more often than you'd think, discover it belongs nowhere new at all.