frontend-large-feature-architecture

Frontend Large Feature Architecture

Use this skill when building, changing, or refactoring a large frontend surface.

In this skill, "controller" means a component or hook that owns feature logic: data fetching, view state, table/list state, effects, actions, and expensive rendering. The problem is not the name; it is one place owning too many changing responsibilities.

Big Feature Rules

When a feature grows, split rendering from logic. Most components should be view-only. Data preparation should be pure. Complex user actions should live in external async functions or local-store actions. Effects are integration boundaries, not the normal way to derive state.

For the full rules, read `references/big-feature-rules.md`.

React Without useEffect

UI is a pure function of state. Do not use useEffect to derive, prepare, or sync data:

• Derived values are computed in render (const title = data?.name ?? ""),

never mirrored into state by an effect. Client state that refers to server data stores only the user's intent (an id) and derives the effective value by merging with query data in render.

• When loaded data seeds editable state, split the component: an outer

data-preparer/controller fetches and renders a loading state (prefer a skeleton; <Spinner /> as minimal fallback); the inner component receives the loaded value as an initialValue prop and seeds useState(initialValue). Do not render UI before its data is ready.

• Define a form only where all initial values are already prepared; if data is

still loading, the form lives deeper in the tree.

• Complex actions live outside React as plain functions using the store or

query client — not inside components, not behind effects.

• useCallback/useMemo are premature optimization; fix re-render problems by

splitting components, not memoizing.

• useEffect is legitimate only for DOM/browser API integration: no (or

minimal) dependencies, one concern, and a cleanup function.

For the golden example and full reasoning, read `references/react-without-useeffect.md`.

Required Model

• The page/view owns lifecycle and creates feature-scoped dependencies.
• Server/query state stays in tRPC/React Query; route state stays in the

router/filter hooks.

• High-frequency feature UI state belongs in a per-mount local vanilla Zustand

store. Create it with lazy useState, not useMemo.

• Global stores are only for truly cross-feature, cross-route product state.
• React context may provide a stable store or action owner. Do not put

frequently changing state directly in provider values.

• Rendered rows/cells/items should be view-only or narrow containers. Put

effects, subscriptions, data loading, and workflows outside expensive views.

• Shared src/components/* exports should stay context-free or receive

explicit props. Put view-scoped Zustand consumers in src/features/*.

• Large feature folders should have a concise README.md owner map.
• Migrate real features toward this model whenever you touch them: improve

state boundaries, action workflows, data-preparation seams, and render boundaries. Hundreds of legacy cases remain — do not preserve a legacy shape just to keep a change small.

Local Store Default

Prefer a local vanilla Zustand store for large or high-frequency feature state. The store is created by the page/view and destroyed on unmount.

Use selectors that return primitives or stable references. If a component needs multiple values, use shallow selector helpers or split subscriptions so one changing field does not rerender unrelated UI.

Complex user workflows should live in actions/*.ts files or store actions. The component wires hooks and passes dependencies; the action owns the workflow.

For a complete effect audit or component-splitting recipes, use `../refactor-react-effects/SKILL.md`.

When To Read References

• For the core big-feature rules and migration reality, read

`references/big-feature-rules.md`.

• For the React-without-useEffect model — derived values, gating render on

loaded data, initialValue props, forms, actions outside React, and why not to memoize — read `references/react-without-useeffect.md`.

• For virtualized lists, translated DOM, row measurement, and scroll rerenders,

read `references/virtualized-lists.md`.

• For local feature stores and splitting large components, read

`references/local-feature-state.md`.

• For feature README.md owner maps, read

`references/feature-readmes.md`.

• For a step-by-step migration from a controller component to a managed feature

pattern, read `references/controller-migration.md`. This is the default reference for traces/observations tables, sessions, experiments, prompts, evals, datasets, and other controller-heavy surfaces.