React Patterns

Overview

Decision-driven guidance for writing idiomatic React. Focus on avoiding common anti-patterns and choosing the right tool for each job.

Quick Decision Trees

Should This Be a useEffect?

Is this synchronizing with an EXTERNAL system?
├─ YES (DOM, network, third-party widget) → useEffect
└─ NO
   ├─ Caused by USER ACTION? → Event handler
   ├─ Can be CALCULATED from state/props? → Render-time calculation
   └─ Runs because component DISPLAYED? → useEffect

Should This Be State?

Can it be computed from existing props/state?
├─ YES → Derive it (const x = ...)
└─ NO
   ├─ Does it change over time? → useState
   └─ NO → Regular variable or prop

Should I Memoize This?

Is the calculation expensive (>1ms)?
├─ NO → Don't memoize
└─ YES
   ├─ Used in render? → useMemo
   └─ Passed to child as prop? → Consider useMemo

Anti-Pattern Quick Reference

When to Load References

Load the specific reference file when working on that area:

• Effects issues: Read(.claude/skills/react-patterns/references/effects.md)
• State structure: Read(.claude/skills/react-patterns/references/state.md)
• Component design: Read(.claude/skills/react-patterns/references/components.md)
• Performance: Read(.claude/skills/react-patterns/references/performance.md)
• Event handling: Read(.claude/skills/react-patterns/references/events.md)

Core Principles

1. Effects are escape hatches - Only for external system sync
2. Derive, don't sync - If computable, compute it
3. State should be minimal - Store IDs not objects, derive the rest
4. Measure before optimizing - No premature useMemo/useCallback
5. Colocate related logic - Keep cause and effect together
6. Data flows down - Avoid passing data up via Effects