frontend-architecturelisted

# Frontend Architecture Most frontend architecture problems aren't visual — they're state living in the wrong place, or a rendering strategy picked by habit instead of by the actual requirement. This skill forces both decisions explicitly. ## Step 1 — Rendering strategy, chosen by requirement, not default Pick SSR/SSG/ISR/CSR based on the actual needs: does this route need SEO (rules out pure CSR), does content update per-request or can it be built ahead of time (SSG/ISR) or does it need per-request personalization (SSR/CSR)? A team defaulting to one strategy across an entire app regardless of per-route requirements is a common, avoidable cost. ## Step 2 — State management boundaries, stated explicitly Separate three categories and say which is which for the app being designed: - **Local component state** — belongs to one component, doesn't need to escape it. - **Shared app state** — genuinely needs to be read/written from multiple, unrelated parts of the tree. - **Server state (cache)** — data that actually lives on a server and is being cached client-side. The most common frontend architecture failure is treating server data as if it were client app state — teams end up hand-rolling cache invalidation, staleness, and refetch logic that a dedicated server-state library already solves. If the app doesn't clearly separate these, that's the finding to raise first, before any component-level review. ## Step 3 — Component data flow State the direction data flows and how: