Frontend Architecture

Concept of the skill

Frontend architecture is the discipline of deciding, on purpose, where code lives, what is allowed to depend on what, who owns mutable state, and how runtime boundaries are reflected in the module graph. Its central insight is that the folder tree you see is only the surface; the architecture that actually governs changeability is the import graph beneath it.

The skill works at four structural layers. Module organization chooses an organizing model - feature-sliced (features/<feature>/{ui,model,api}), layered (components/, hooks/, services/, pages/), domain-driven (domains/<domain>/{ui,logic,data}), route-colocated, or package/workspace-based - and accepts its trade-offs as the codebase scales. Component layering separates pure primitives, feature-composed components, and connected or route-level components, watching the composed-to-connected boundary where most dependency tangles begin. State ownership decides location, normalization, derivation, write ownership, and cache ownership for each piece of state, keeping remote server state separate from ephemeral client state. Import-direction enforcement turns the desired structure into a checkable rule: shared modules do not import features, features do not import sibling features, features do not import route files, and clients do not pull server-only modules into the browser.

This is not a folder-naming skill. The goal is an import graph that makes change cheap: feature code is cohesive and removable, shared primitives are truly feature-agnostic, route files are thin orchestration or registration points, state has one owner, and public module APIs prevent consumers from depending on internal file layout.

Coverage

Boundary Triage

Before reorganizing, classify the decision: