Frontend Architecture
State shape: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the shape decisions stick.
Reconstruct the unit’s core decisions — derived vs stored, server cache vs client state, colocation, URL as source of truth, and normalization — without looking back at the lesson.
- 01What is the test for whether a value is state or derived, and why does storing a derived value cause bugs?
- 02Why is 'server cache vs client state' the most important shape question, and how does it change your tooling?
- 03What does colocation mean, why does it make an app faster, and how is it different from 'lift state up'?
- 04Which kinds of state belong in the URL, and what breaks when you keep them only in useState?
- 05When should client state be normalized, and what exactly is the tradeoff against a nested shape?
- 06Walk through the ordered questions a senior asks to decide where any value belongs.
If you could reconstruct each answer from memory, you hold the unit’s spine: derive what is derivable so it cannot drift, recognise fetched data as server cache and give it to a cache library, colocate private client state at its lowest reader instead of hoisting it, put shareable view-state in the URL, and normalize relational data only when you mutate it. The single decision tree — derivable? server or client? shareable? lowest reader? — is what prevents the shape bugs the whole unit warned about.