frontend-large-feature-architecture

name	frontend-large-feature-architecture
description	Use when building, changing, or refactoring large Langfuse frontend features, virtualized lists, large tables, controller components, local feature state, Zustand stores, row selection, high-frequency UI state, or rendering-performance issues.

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.

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 through small PRs that improve one state boundary, action workflow, data-preparation seam, or render boundary.

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.

When To Read References

• For the core big-feature rules and migration reality, read references/big-feature-rules.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.