JavaScript and React patterns

Choose a pattern only after identifying the concrete problem it solves. Treat patterns as descriptive options, not mandatory architecture.

Select with evidence

1. Inspect the repository's framework and package versions, local conventions, accepted decisions, and the code at the affected seam. State the observed pressure: coupling, ownership, reuse, loading, rendering, data flow, or measured performance.
2. Read the pattern catalog. Shortlist the smallest plausible set, including the direct no-pattern alternative.
3. Read only the linked reference cards for the live candidates. Do not load unrelated cards.
4. Compare interface cost, hidden complexity, runtime cost, testability, migration cost, and fit with the existing stack. Verify time-sensitive APIs against the installed version and its official documentation.
5. Apply or recommend a pattern only when its benefit is observable in the current problem. Preserve simpler code when the pattern merely renames or redistributes complexity.
6. Validate at the narrowest faithful seam. Use behavior tests for structural changes and profiler, bundle, network, or Web Vitals evidence for performance claims.

Completion criterion: the result names the problem and evidence, the direct alternative, the selected reference, applicable tradeoffs and version constraints, the authorized action taken, and its validation.

Modern React baseline