Frontend Architecture
Data fetching: 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 unit’s mental model stick.
Reconstruct the unit’s spine — why fetch location decides LCP, how waterfalls form and dissolve, what RSC streaming and the SWR cache each buy, and how multi-layer invalidation works — without looking back at the lessons.
- 01Why does the location of a data fetch decide LCP more than network speed?
- 02Why do component-level useEffect fetches form a waterfall even when the data is independent, and what three patterns dissolve it?
- 03What is the 'use client' boundary rule, and what does marking everything 'use client' cost?
- 04Explain stale-while-revalidate and single-flight deduplication in TanStack Query / SWR.
- 05What is the canonical optimistic-update pattern, and what is the classic bug?
- 06Name the cache layers in a Next.js 15 app and why a mutation must invalidate more than one.
If you could reconstruct each answer from memory, you hold the unit’s spine: fetch location sets the round-trip count on the critical path and therefore LCP; the render cascade serialises independent fetches into waterfalls that Promise.all, useQueries, or sibling RSC components dissolve; Server Components ship zero JS only when they stay server-side, and Suspense streaming buys a low TTFB; the client cache makes revisits instant via stale-while-revalidate and single-flight, with optimistic updates demanding a full snapshot; and every mutation must invalidate every cache layer it touches — server revalidation alone is not enough.