| 1 | # React Composition Patterns |
| 2 | |
| 3 | A structured repository for React composition patterns that scale. These |
| 4 | patterns help avoid boolean prop proliferation by using compound components, |
| 5 | lifting state, and composing internals. |
| 6 | |
| 7 | ## Structure |
| 8 | |
| 9 | - `rules/` - Individual rule files (one per rule) |
| 10 | - `_sections.md` - Section metadata (titles, impacts, descriptions) |
| 11 | - `_template.md` - Template for creating new rules |
| 12 | - `area-description.md` - Individual rule files |
| 13 | - `metadata.json` - Document metadata (version, organization, abstract) |
| 14 | - **`AGENTS.md` |
| 15 | |
| 16 | ## Rules |
| 17 | |
| 18 | ### Component Architecture (CRITICAL) |
| 19 | |
| 20 | - `architecture-avoid-boolean-props.md` - Don't add boolean props to customize |
| 21 | behavior |
| 22 | - `architecture-compound-components.md` - Structure as compound components with |
| 23 | shared context |
| 24 | |
| 25 | ### State Management (HIGH) |
| 26 | |
| 27 | - `state-lift-state.md` - Lift state into provider components |
| 28 | - `state-context-interface.md` - Define clear context interfaces |
| 29 | (state/actions/meta) |
| 30 | - `state-decouple-implementation.md` - Decouple state management from UI |
| 31 | |
| 32 | ### Implementation Patterns (MEDIUM) |
| 33 | |
| 34 | - `patterns-children-over-render-props.md` - Prefer children over renderX props |
| 35 | - `patterns-explicit-variants.md` - Create explicit component variants |
| 36 | |
| 37 | ## Core Principles |
| 38 | |
| 39 | 1. **Composition over configuration** — Instead of adding props, let consumers |
| 40 | compose |
| 41 | 2. **Lift your state** — State in providers, not trapped in components |
| 42 | 3. **Compose your internals** — Subcomponents access context, not props |
| 43 | 4. **Explicit variants** — Create ThreadComposer, EditComposer, not Composer |
| 44 | with isThread |
| 45 | |
| 46 | ## Creating a New Rule |
| 47 | |
| 48 | 1. Copy `rules/_template.md` to `rules/area-description.md` |
| 49 | 2. Choose the appropriate area prefix: |
| 50 | - `architecture-` for Component Architecture |
| 51 | - `state-` for State Management |
| 52 | - `patterns-` for Implementation Patterns |
| 53 | 3. Fill in the frontmatter and content |
| 54 | 4. Ensure you have clear examples with explanations |
| 55 | |
| 56 | ## Impact Levels |
| 57 | |
| 58 | - `CRITICAL` - Foundational patterns, prevents unmaintainable code |
| 59 | - `HIGH` - Significant maintainability improvements |
| 60 | - `MEDIUM` - Good practices for cleaner code |