--- name: react-composition-patterns model: standard --- # React Composition Patterns Build flexible, maintainable React components using compound components, context providers, and explicit variants. Avoid boolean prop proliferation. ## WHAT Composition patterns that scale: - Compound components with shared context - State/actions/meta context interface for dependency injection - Explicit variant components over boolean props - Lifted state in provider components - Children composition over render props ## WHEN - Refactoring components with many boolean props - Building reusable component libraries - Designing flexible component APIs - Creating compound components (Card, Dialog, Form, etc.) - Components need shared state across sibling elements ## KEYWORDS composition, compound components, context, provider, boolean props, variants, react patterns, component architecture, render props, children **Source:** Vercel Engineering ## Installation ### OpenClaw / Moltbot / Clawbot ```bash npx clawhub@latest install composition-patterns ``` --- ## Core Principle **Avoid boolean prop proliferation.** Each boolean doubles possible states. ```tsx // BAD: 4 booleans = 16 possible states // GOOD: Explicit variants, clear intent ``` --- ## Pattern 1: Compound Components Structure complex components with shared context. Consumers compose what they need. ```tsx const ComposerContext = createContext(null) // Provider handles state function ComposerProvider({ children, state, actions, meta }: ProviderProps) { return ( {children} ) } // Subcomponents access context function ComposerInput() { const { state, actions: { update }, meta: { inputRef } } = use(ComposerContext) return ( update(s => ({ ...s, input: text }))} /> ) } function ComposerSubmit() { const { actions: { submit } } = use(ComposerContext) return } // Export as namespace const Composer = { Provider: ComposerProvider, Frame: ComposerFrame, Input: ComposerInput, Submit: ComposerSubmit, Header: ComposerHeader, Footer: ComposerFooter, } ``` **Usage:** ```tsx ``` --- ## Pattern 2: Generic Context Interface Define a contract any provider can implement: `state`, `actions`, `meta`. ```tsx interface ComposerState { input: string attachments: Attachment[] isSubmitting: boolean } interface ComposerActions { update: (updater: (state: ComposerState) => ComposerState) => void submit: () => void } interface ComposerMeta { inputRef: React.RefObject } interface ComposerContextValue { state: ComposerState actions: ComposerActions meta: ComposerMeta } ``` **Same UI, different providers:** ```tsx // Local state provider function ForwardMessageProvider({ children }) { const [state, setState] = useState(initialState) return ( {children} ) } // Global synced state provider function ChannelProvider({ channelId, children }) { const { state, update, submit } = useGlobalChannel(channelId) return ( {children} ) } ``` Both work with the same `` component. --- ## Pattern 3: Explicit Variants Create named components for each use case instead of boolean modes. ```tsx // BAD: What does this render? // GOOD: Self-documenting ``` **Implementation:** ```tsx function ThreadComposer({ channelId }: { channelId: string }) { return ( ) } function EditComposer({ messageId }: { messageId: string }) { return ( ) } ``` --- ## Pattern 4: Lifted State Components outside the visual hierarchy can access state via provider. ```tsx function ForwardMessageDialog() { return ( ) } // Can access context despite being outside Composer.Frame function ForwardButton() { const { actions: { submit } } = use(ComposerContext) return } function MessagePreview() { const { state } = use(ComposerContext) return } ``` **Key insight:** Provider boundary matters, not visual nesting. --- ## Pattern 5: Children Over Render Props Use children for composition, render props only when passing data. ```tsx // BAD: Render props for structure } renderFooter={() => } renderActions={() => } /> // GOOD: Children for structure ``` **When render props ARE appropriate:** ```tsx // Passing data to children } /> ``` --- ## Pattern 6: Decouple State from UI Only the provider knows how state is managed. UI consumes the interface. ```tsx // BAD: UI coupled to state implementation function ChannelComposer({ channelId }) { const state = useGlobalChannelState(channelId) // Knows about global state const { submit } = useChannelSync(channelId) // Knows about sync return } // GOOD: State isolated in provider function ChannelProvider({ channelId, children }) { const { state, update, submit } = useGlobalChannel(channelId) return ( {children} ) } // UI only knows the interface function ChannelComposer() { return ( {/* Works with any provider */} ) } ``` --- ## Quick Reference | Anti-Pattern | Solution | |--------------|----------| | Boolean props | Explicit variant components | | Render props for structure | Children composition | | State in component | Lift to provider | | Coupled to state impl | Generic context interface | | Many conditional renders | Compose pieces explicitly | --- ## Files - `rules/architecture-avoid-boolean-props.md` - Detailed boolean prop guidance - `rules/architecture-compound-components.md` - Compound component pattern - `rules/state-context-interface.md` - Context interface design - `rules/state-decouple-implementation.md` - State isolation - `rules/state-lift-state.md` - Provider pattern - `rules/patterns-explicit-variants.md` - Variant components - `rules/patterns-children-over-render-props.md` - Composition over callbacks --- ## NEVER - Add boolean props to customize behavior (use composition) - Create components with more than 2-3 boolean mode props - Couple UI components to specific state implementations - Use render props when children would work - Trap state inside components when siblings need access

composition-patterns

Scan your own AI components