Frontend Architecture
State shape: multiple-choice review
Crux Multiple-choice synthesis across the state-shape unit — derived state, server cache vs client state, colocation, URL state, and normalization tradeoffs.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each mirrors a decision you make before reaching for any state library — not a definition to recite, but a shape to choose under real constraints.
Goal
Confirm you can connect the unit’s spine: derive what is derivable, separate server cache from client state, colocate at the lowest reader, push shareable view-state to the URL, and normalize relational data only when it is mutated.
Quiz
Completed
A products list is fetched from an API and read by three sibling components on the same screen. What is the correct shape?
Heads-up Three copies means three fetches and three sources of truth that drift the moment one refetches or a mutation lands. The data is one thing, owned by the server.
Heads-up A plain slice models fetched data as client state, so you hand-roll staleness, dedupe, refetch, and invalidation — usually with bugs. That is exactly what a server-cache library exists to remove.
Heads-up The URL is for shareable view-state (filters, ids, pagination), not for caching a fetched payload. A list of product objects does not belong in the address bar.
Quiz
Completed
A count badge reads '127' while the list shows 9 rows; count lives in useState next to the results array. What is the root cause and the senior fix?
Heads-up Re-rendering does not help: the stored count value itself is wrong. The defect is that two values that are the same fact are stored separately and one update path missed the copy.
Heads-up useMemo is a performance tool, not a correctness one. A memoized copy is still a second source of truth — deriving during render is what removes the drift entirely.
Heads-up Globalising a derived value does not fix drift — it spreads it, and adds a re-render blast radius on top. The only fix is to not store a value you can compute.
Quiz
Completed
A tooltip's open/closed boolean is stored in the root app store 'so it is available everywhere'. Why is this the wrong shape?
Heads-up Size is not the criterion — readership is. A large object read by one subtree still colocates; a tiny boolean read app-wide might justify global state. The tooltip's flag has exactly one reader.
Heads-up Any store holds booleans fine. The problem is not the type, it is placing state far above its only reader, which inflates the re-render blast radius.
Heads-up 'Lift state up' is routinely over-applied. Lifting to the root is how a tooltip's flag ends up re-rendering a dashboard. Colocation means pushing state down to the lowest reader.
Quiz
Completed
Filters and the open detail id are stored only in useState. A copied link opens an empty default view for a teammate, and refreshing also resets everything. What shape was missed?
Heads-up localStorage survives refresh but is per-device — a copied link still opens the default view for a teammate. URL state is what makes the view shareable and restorable across machines.
Heads-up Filters and the open id are client-owned view-state, not server data. A cache library keyed by request does not make a view shareable; the URL does.
Heads-up A global store is still in-memory and lost on refresh, and it does not appear in a copied link. The defining property here is shareability, which only the URL provides.
Quiz
Completed
A client-side editor holds threads, posts, and users nested as the API returned them, and users get renamed constantly. After a rename, some views still show the old name. Why, and what shape fixes it?
Heads-up The views did re-render — they read a stale embedded copy that was never updated. The defect is the shape duplicating one user across the tree, not a missing render.
Heads-up Normalization is for frequently-mutated relational client state. Read-mostly server data should stay as the raw response in the cache library; normalizing it adds ceremony with no payoff.
Heads-up Deep-merging every embedded copy reinvents normalization badly and stays error-prone. Storing each entity once in a byId map removes the duplication that causes the drift.
Quiz
Completed
A team stores selectedUser as the full user object in state. After an edit elsewhere updates that user, the selection still shows the old fields. What is the shape lesson?
Heads-up That is the derived-state trap again: now every edit path must remember to rewrite the snapshot. Storing the id and joining at read time removes the invariant entirely.
Heads-up The UI joins the id against the cache (byId[selectedId]) to get current fields. The id is the minimal real state; the object is a derived view of it.
Heads-up A frozen clone is precisely the stale snapshot problem — it never reflects later edits. The fix is to store the id and re-join, not to capture a copy.
Recap
The through-line of the unit is one decision tree: if a value is derivable (count, the selected object), do not store it — compute it during render or join it from the id. If it is state, ask who owns it — server-fetched data is cache (React Query/SWR), client view-state that is shareable goes in the URL, and the rest colocates at the lowest common ancestor of its readers to keep the re-render blast radius small. Normalize relational client data into a byId map only when you mutate it. Every distractor above is a real shape mistake — globalising a derived value, caching fetched data as client state, hoisting a single-reader flag to the root, or snapshotting an object that should be a joined id.