Vercel Composition Patterns

JetBrainsOfficialCreated by VercelDistributed by JetBrains

Skill
Guidelines
Software development
MIT
No issues found

From the author

React composition patterns that scale. Use when refactoring components with boolean prop proliferation, building flexible component libraries, or designing reusable APIs. Triggers on tasks involving compound components, render props, context providers, or component architecture. Includes React 19 API changes.

— the description by Vercel

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured set of guidelines for designing flexible, maintainable React components. It focuses on replacing complex boolean prop configurations with robust composition patterns such as compound components, context providers, and explicit variants. The guide is designed to help developers and AI agents create cleaner, more scalable component APIs, including specific considerations for React 19 API updates.

What it does

Provides architectural patterns to eliminate boolean prop proliferation.
Defines best practices for compound components and shared context usage.
Offers guidance on state management and decoupling implementation details.
Includes specific rules for leveraging modern React 19 APIs.
Encourages the use of children over render props for better composition.
Standardizes component API design for improved maintainability.

When to use it

When refactoring components that have become difficult to manage due to excessive boolean props.
During the design phase of a reusable component library.
When evaluating or reviewing existing component architecture for scalability.
When implementing complex state sharing between sibling components.
When upgrading or building new features using React 19.

Advantages

Reduces technical debt caused by complex, hard-to-maintain component APIs.
Improves code readability for both human developers and AI agents.
Promotes a consistent architectural style across the codebase.
Ensures component designs are flexible and easier to extend over time.

Usage examples

“How can I refactor a button component that has too many boolean props like 'isPrimary', 'isLarge', and 'isDisabled'?”: The agent will suggest using explicit variant components or a composition-based approach to replace boolean flags with more descriptive, scalable patterns.
“What is the recommended way to share state between complex compound components in React 19?”: The agent will provide guidance on using context providers and the latest React 19 APIs to decouple state management from the component structure.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/jetbrains/vercel-composition-patterns/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip vercel-composition-patterns.zip -d .agents/skills

Documentation by Vercel

React Composition Patterns

Composition patterns for building flexible, maintainable React components. Avoid boolean prop proliferation by using compound components, lifting state, and composing internals. These patterns make codebases easier for both humans and AI agents to work with as they scale.

When to Apply

Reference these guidelines when:

Refactoring components with many boolean props
Building reusable component libraries
Designing flexible component APIs
Reviewing component architecture
Working with compound components or context providers

Rule Categories by Priority

Priority	Category	Impact	Prefix
1	Component Architecture	HIGH	`architecture-`
2	State Management	MEDIUM	`state-`
3	Implementation Patterns	MEDIUM	`patterns-`
4	React 19 APIs	MEDIUM	`react19-`

Quick Reference

1. Component Architecture (HIGH)

architecture-avoid-boolean-props - Don't add boolean props to customize behavior; use composition
architecture-compound-components - Structure complex components with shared context

2. State Management (MEDIUM)

state-decouple-implementation - Provider is the only place that knows how state is managed
state-context-interface - Define generic interface with state, actions, meta for dependency injection
state-lift-state - Move state into provider components for sibling access

3. Implementation Patterns (MEDIUM)

patterns-explicit-variants - Create explicit variant components instead of boolean modes
patterns-children-over-render-props - Use children for composition instead of renderX props

4. React 19 APIs (MEDIUM)

⚠️ React 19+ only. Skip this section if using React 18 or earlier.

react19-no-forwardref - Don't use forwardRef; use use() instead of useContext()

How to Use

Read individual rule files for detailed explanations and code examples:

rules/architecture-avoid-boolean-props.md
rules/state-context-interface.md

Each rule file contains:

Brief explanation of why it matters
Incorrect code example with explanation
Correct code example with explanation
Additional context and references

Full Compiled Document

For the complete guide with all rules expanded: AGENTS.md

Files

AGENTS.md22.1 KiB
ATTRIBUTION.mdAdded by AutoGineer864 B
README.md2.1 KiB
SKILL.md3.0 KiB
metadata.json530 B
rules/_sections.md829 B
rules/_template.md329 B
rules/architecture-avoid-boolean-props.md2.2 KiB
rules/architecture-compound-components.md2.5 KiB
rules/patterns-children-over-render-props.md1.8 KiB
rules/patterns-explicit-variants.md2.3 KiB
rules/react19-no-forwardref.md953 B
rules/state-context-interface.md4.9 KiB
rules/state-decouple-implementation.md2.6 KiB
rules/state-lift-state.md3.1 KiB

AGENTS.md

React Composition Patterns

Version 1.0.0
Engineering
January 2026

Note:
This document is mainly for agents and LLMs to follow when maintaining,
generating, or refactoring React codebases using composition. Humans
may also find it useful, but guidance here is optimized for automation
and consistency by AI-assisted workflows.

Abstract

Component Architecture — HIGH
- 1.1 Avoid Boolean Prop Proliferation
- 1.2 Use Compound Components
State Management — MEDIUM
- 2.1 Decouple State Management from UI
- 2.2 Define Generic Context Interfaces for Dependency Injection
- 2.3 Lift State into Provider Components
Implementation Patterns — MEDIUM
- 3.1 Create Explicit Component Variants
- 3.2 Prefer Composing Children Over Render Props
React 19 APIs — MEDIUM
- 4.1 React 19 API Changes

1. Component Architecture

Impact: HIGH

Fundamental patterns for structuring components to avoid prop proliferation and enable flexible composition.

1.1 Avoid Boolean Prop Proliferation

Impact: CRITICAL (prevents unmaintainable component variants)

Don't add boolean props like isThread, isEditing, isDMThread to customize

component behavior. Each boolean doubles possible states and creates

unmaintainable conditional logic. Use composition instead.

Incorrect: boolean props create exponential complexity

function Composer({
  onSubmit,
  isThread,
  channelId,
  isDMThread,
  dmId,
  isEditing,
  isForwarding,
}: Props) {
  return (
    <form>
      <Header />
      <Input />
      {isDMThread ? (
        <AlsoSendToDMField id={dmId} />
      ) : isThread ? (
        <AlsoSendToChannelField id={channelId} />
      ) : null}
      {isEditing ? (
        <EditActions />
      ) : isForwarding ? (
        <ForwardActions />
      ) : (
        <DefaultActions />
      )}
      <Footer onSubmit={onSubmit} />
    </form>
  )
}

Correct: composition eliminates conditionals

// Channel composer
function ChannelComposer() {
  return (
    <Composer.Frame>
      <Composer.Header />
      <Composer.Input />
      <Composer.Footer>
        <Composer.Attachments />
        <Composer.Formatting />
        <Composer.Emojis />
        <Composer.Submit />
      </Composer.Footer>
    </Composer.Frame>
  )
}

// Thread composer - adds "also send to channel" field
function ThreadComposer({ channelId }: { channelId: string }) {
  return (
    <Composer.Frame>
      <Composer.Header />
      <Composer.Input />
      <AlsoSendToChannelField id={channelId} />
      <Composer.Footer>
        <Composer.Formatting />
        <Composer.Emojis />
        <Composer.Submit />
      </Composer.Footer>
    </Composer.Frame>
  )
}

// Edit composer - different footer actions
function EditComposer() {
  return (
    <Composer.Frame>
      <Composer.Input />
      <Composer.Footer>
        <Composer.Formatting />
        <Composer.Emojis />
        <Composer.CancelEdit />
        <Composer.SaveEdit />
      </Composer.Footer>
    </Composer.Frame>
  )
}

Each variant is explicit about what it renders. We can share internals without

sharing a single monolithic parent.

1.2 Use Compound Components

Impact: HIGH (enables flexible composition without prop drilling)

Structure complex components as compound components with a shared context. Each

subcomponent accesses shared state via context, not props. Consumers compose the

pieces they need.

Incorrect: monolithic component with render props

function Composer({
  renderHeader,
  renderFooter,
  renderActions,
  showAttachments,
  showFormatting,
  showEmojis,
}: Props) {
  return (
    <form>
      {renderHeader?.()}
      <Input />
      {showAttachments && <Attachments />}
      {renderFooter ? (
        renderFooter()
      ) : (
        <Footer>
          {showFormatting && <Formatting />}
          {showEmojis && <Emojis />}
          {renderActions?.()}
        </Footer>
      )}
    </form>
  )
}

Correct: compound components with shared context

const ComposerContext = createContext<ComposerContextValue | null>(null)

function ComposerProvider({ children, state, actions, meta }: ProviderProps) {
  return (
    <ComposerContext value={{ state, actions, meta }}>
      {children}
    </ComposerContext>
  )
}

function ComposerFrame({ children }: { children: React.ReactNode }) {
  return <form>{children}</form>
}

function ComposerInput() {
  const {
    state,
    actions: { update },
    meta: { inputRef },
  } = use(ComposerContext)
  return (
    <TextInput
      ref={inputRef}
      value={state.input}
      onChangeText={(text) => update((s) => ({ ...s, input: text }))}
    />
  )
}

function ComposerSubmit() {
  const {
    actions: { submit },
  } = use(ComposerContext)
  return <Button onPress={submit}>Send</Button>
}

// Export as compound component
const Composer = {
  Provider: ComposerProvider,
  Frame: ComposerFrame,
  Input: ComposerInput,
  Submit: ComposerSubmit,
  Header: ComposerHeader,
  Footer: ComposerFooter,
  Attachments: ComposerAttachments,
  Formatting: ComposerFormatting,
  Emojis: ComposerEmojis,
}

Usage:

<Composer.Provider state={state} actions={actions} meta={meta}>
  <Composer.Frame>
    <Composer.Header />
    <Composer.Input />
    <Composer.Footer>
      <Composer.Formatting />
      <Composer.Submit />
    </Composer.Footer>
  </Composer.Frame>
</Composer.Provider>

Consumers explicitly compose exactly what they need. No hidden conditionals. And the state, actions and meta are dependency-injected by a parent provider, allowing multiple usages of the same component structure.

2. State Management

Impact: MEDIUM

Patterns for lifting state and managing shared context across composed components.

2.1 Decouple State Management from UI

Impact: MEDIUM (enables swapping state implementations without changing UI)

The provider component should be the only place that knows how state is managed.

UI components consume the context interface—they don't know if state comes from

useState, Zustand, or a server sync.

Incorrect: UI coupled to state implementation

function ChannelComposer({ channelId }: { channelId: string }) {
  // UI component knows about global state implementation
  const state = useGlobalChannelState(channelId)
  const { submit, updateInput } = useChannelSync(channelId)

  return (
    <Composer.Frame>
      <Composer.Input
        value={state.input}
        onChange={(text) => sync.updateInput(text)}
      />
      <Composer.Submit onPress={() => sync.submit()} />
    </Composer.Frame>
  )
}

Correct: state management isolated in provider

// Provider handles all state management details
function ChannelProvider({
  channelId,
  children,
}: {
  channelId: string
  children: React.ReactNode
}) {
  const { state, update, submit } = useGlobalChannel(channelId)
  const inputRef = useRef(null)

  return (
    <Composer.Provider
      state={state}
      actions={{ update, submit }}
      meta={{ inputRef }}
    >
      {children}
    </Composer.Provider>
  )
}

// UI component only knows about the context interface
function ChannelComposer() {
  return (
    <Composer.Frame>
      <Composer.Header />
      <Composer.Input />
      <Composer.Footer>
        <Composer.Submit />
      </Composer.Footer>
    </Composer.Frame>
  )
}

// Usage
function Channel({ channelId }: { channelId: string }) {
  return (
    <ChannelProvider channelId={channelId}>
      <ChannelComposer />
    </ChannelProvider>
  )
}

Different providers, same UI:

// Local state for ephemeral forms
function ForwardMessageProvider({ children }) {
  const [state, setState] = useState(initialState)
  const forwardMessage = useForwardMessage()

  return (
    <Composer.Provider
      state={state}
      actions={{ update: setState, submit: forwardMessage }}
    >
      {children}
    </Composer.Provider>
  )
}

// Global synced state for channels
function ChannelProvider({ channelId, children }) {
  const { state, update, submit } = useGlobalChannel(channelId)

  return (
    <Composer.Provider state={state} actions={{ update, submit }}>
      {children}
    </Composer.Provider>
  )
}

The same Composer.Input component works with both providers because it only

depends on the context interface, not the implementation.

2.2 Define Generic Context Interfaces for Dependency Injection

Impact: HIGH (enables dependency-injectable state across use-cases)

Define a generic interface for your component context with three parts:

state, actions, and meta. This interface is a contract that any provider

can implement—enabling the same UI components to work with completely different

state implementations.

Core principle: Lift state, compose internals, make state

dependency-injectable.

Incorrect: UI coupled to specific state implementation

function ComposerInput() {
  // Tightly coupled to a specific hook
  const { input, setInput } = useChannelComposerState()
  return <TextInput value={input} onChangeText={setInput} />
}

Correct: generic interface enables dependency injection

// Define a GENERIC interface that any provider can implement
interface ComposerState {
  input: string
  attachments: Attachment[]
  isSubmitting: boolean
}

interface ComposerActions {
  update: (updater: (state: ComposerState) => ComposerState) => void
  submit: () => void
}

interface ComposerMeta {
  inputRef: React.RefObject<TextInput>
}

interface ComposerContextValue {
  state: ComposerState
  actions: ComposerActions
  meta: ComposerMeta
}

const ComposerContext = createContext<ComposerContextValue | null>(null)

UI components consume the interface, not the implementation:

function ComposerInput() {
  const {
    state,
    actions: { update },
    meta,
  } = use(ComposerContext)

  // This component works with ANY provider that implements the interface
  return (
    <TextInput
      ref={meta.inputRef}
      value={state.input}
      onChangeText={(text) => update((s) => ({ ...s, input: text }))}
    />
  )
}

Different providers implement the same interface:

// Provider A: Local state for ephemeral forms
function ForwardMessageProvider({ children }: { children: React.ReactNode }) {
  const [state, setState] = useState(initialState)
  const inputRef = useRef(null)
  const submit = useForwardMessage()

  return (
    <ComposerContext
      value={{
        state,
        actions: { update: setState, submit },
        meta: { inputRef },
      }}
    >
      {children}
    </ComposerContext>
  )
}

// Provider B: Global synced state for channels
function ChannelProvider({ channelId, children }: Props) {
  const { state, update, submit } = useGlobalChannel(channelId)
  const inputRef = useRef(null)

  return (
    <ComposerContext
      value={{
        state,
        actions: { update, submit },
        meta: { inputRef },
      }}
    >
      {children}
    </ComposerContext>
  )
}

The same composed UI works with both:

// Works with ForwardMessageProvider (local state)
<ForwardMessageProvider>
  <Composer.Frame>
    <Composer.Input />
    <Composer.Submit />
  </Composer.Frame>
</ForwardMessageProvider>

// Works with ChannelProvider (global synced state)
<ChannelProvider channelId="abc">
  <Composer.Frame>
    <Composer.Input />
    <Composer.Submit />
  </Composer.Frame>
</ChannelProvider>

Custom UI outside the component can access state and actions:

function ForwardMessageDialog() {
  return (
    <ForwardMessageProvider>
      <Dialog>
        {/* The composer UI */}
        <Composer.Frame>
          <Composer.Input placeholder="Add a message, if you'd like." />
          <Composer.Footer>
            <Composer.Formatting />
            <Composer.Emojis />
          </Composer.Footer>
        </Composer.Frame>

        {/* Custom UI OUTSIDE the composer, but INSIDE the provider */}
        <MessagePreview />

        {/* Actions at the bottom of the dialog */}
        <DialogActions>
          <CancelButton />
          <ForwardButton />
        </DialogActions>
      </Dialog>
    </ForwardMessageProvider>
  )
}

// This button lives OUTSIDE Composer.Frame but can still submit based on its context!
function ForwardButton() {
  const {
    actions: { submit },
  } = use(ComposerContext)
  return <Button onPress={submit}>Forward</Button>
}

// This preview lives OUTSIDE Composer.Frame but can read composer's state!
function MessagePreview() {
  const { state } = use(ComposerContext)
  return <Preview message={state.input} attachments={state.attachments} />
}

The provider boundary is what matters—not the visual nesting. Components that

need shared state don't have to be inside the Composer.Frame. They just need

to be within the provider.

The ForwardButton and MessagePreview are not visually inside the composer

box, but they can still access its state and actions. This is the power of

lifting state into providers.

The UI is reusable bits you compose together. The state is dependency-injected

by the provider. Swap the provider, keep the UI.

2.3 Lift State into Provider Components

Impact: HIGH (enables state sharing outside component boundaries)

Move state management into dedicated provider components. This allows sibling

components outside the main UI to access and modify state without prop drilling

or awkward refs.

Incorrect: state trapped inside component

function ForwardMessageComposer() {
  const [state, setState] = useState(initialState)
  const forwardMessage = useForwardMessage()

  return (
    <Composer.Frame>
      <Composer.Input />
      <Composer.Footer />
    </Composer.Frame>
  )
}

// Problem: How does this button access composer state?
function ForwardMessageDialog() {
  return (
    <Dialog>
      <ForwardMessageComposer />
      <MessagePreview /> {/* Needs composer state */}
      <DialogActions>
        <CancelButton />
        <ForwardButton /> {/* Needs to call submit */}
      </DialogActions>
    </Dialog>
  )
}

Incorrect: useEffect to sync state up

function ForwardMessageDialog() {
  const [input, setInput] = useState('')
  return (
    <Dialog>
      <ForwardMessageComposer onInputChange={setInput} />
      <MessagePreview input={input} />
    </Dialog>
  )
}

function ForwardMessageComposer({ onInputChange }) {
  const [state, setState] = useState(initialState)
  useEffect(() => {
    onInputChange(state.input) // Sync on every change 😬
  }, [state.input])
}

Incorrect: reading state from ref on submit

function ForwardMessageDialog() {
  const stateRef = useRef(null)
  return (
    <Dialog>
      <ForwardMessageComposer stateRef={stateRef} />
      <ForwardButton onPress={() => submit(stateRef.current)} />
    </Dialog>
  )
}

Correct: state lifted to provider

function ForwardMessageProvider({ children }: { children: React.ReactNode }) {
  const [state, setState] = useState(initialState)
  const forwardMessage = useForwardMessage()
  const inputRef = useRef(null)

  return (
    <Composer.Provider
      state={state}
      actions={{ update: setState, submit: forwardMessage }}
      meta={{ inputRef }}
    >
      {children}
    </Composer.Provider>
  )
}

function ForwardMessageDialog() {
  return (
    <ForwardMessageProvider>
      <Dialog>
        <ForwardMessageComposer />
        <MessagePreview /> {/* Custom components can access state and actions */}
        <DialogActions>
          <CancelButton />
          <ForwardButton /> {/* Custom components can access state and actions */}
        </DialogActions>
      </Dialog>
    </ForwardMessageProvider>
  )
}

function ForwardButton() {
  const { actions } = use(Composer.Context)
  return <Button onPress={actions.submit}>Forward</Button>
}

The ForwardButton lives outside the Composer.Frame but still has access to the

submit action because it's within the provider. Even though it's a one-off

component, it can still access the composer's state and actions from outside the

UI itself.

Key insight: Components that need shared state don't have to be visually

nested inside each other—they just need to be within the same provider.

3. Implementation Patterns

Impact: MEDIUM

Specific techniques for implementing compound components and context providers.

3.1 Create Explicit Component Variants

Impact: MEDIUM (self-documenting code, no hidden conditionals)

Instead of one component with many boolean props, create explicit variant

components. Each variant composes the pieces it needs. The code documents

itself.

Incorrect: one component, many modes

// What does this component actually render?
<Composer
  isThread
  isEditing={false}
  channelId='abc'
  showAttachments
  showFormatting={false}
/>

Correct: explicit variants

// Immediately clear what this renders
<ThreadComposer channelId="abc" />

// Or
<EditMessageComposer messageId="xyz" />

// Or
<ForwardMessageComposer messageId="123" />

Each implementation is unique, explicit and self-contained. Yet they can each

use shared parts.

Implementation:

function ThreadComposer({ channelId }: { channelId: string }) {
  return (
    <ThreadProvider channelId={channelId}>
      <Composer.Frame>
        <Composer.Input />
        <AlsoSendToChannelField channelId={channelId} />
        <Composer.Footer>
          <Composer.Formatting />
          <Composer.Emojis />
          <Composer.Submit />
        </Composer.Footer>
      </Composer.Frame>
    </ThreadProvider>
  )
}

function EditMessageComposer({ messageId }: { messageId: string }) {
  return (
    <EditMessageProvider messageId={messageId}>
      <Composer.Frame>
        <Composer.Input />
        <Composer.Footer>
          <Composer.Formatting />
          <Composer.Emojis />
          <Composer.CancelEdit />
          <Composer.SaveEdit />
        </Composer.Footer>
      </Composer.Frame>
    </EditMessageProvider>
  )
}

function ForwardMessageComposer({ messageId }: { messageId: string }) {
  return (
    <ForwardMessageProvider messageId={messageId}>
      <Composer.Frame>
        <Composer.Input placeholder="Add a message, if you'd like." />
        <Composer.Footer>
          <Composer.Formatting />
          <Composer.Emojis />
          <Composer.Mentions />
        </Composer.Footer>
      </Composer.Frame>
    </ForwardMessageProvider>
  )
}

Each variant is explicit about:

What provider/state it uses
What UI elements it includes
What actions are available

No boolean prop combinations to reason about. No impossible states.

3.2 Prefer Composing Children Over Render Props

Impact: MEDIUM (cleaner composition, better readability)

Use children for composition instead of renderX props. Children are more

readable, compose naturally, and don't require understanding callback

signatures.

Incorrect: render props

function Composer({
  renderHeader,
  renderFooter,
  renderActions,
}: {
  renderHeader?: () => React.ReactNode
  renderFooter?: () => React.ReactNode
  renderActions?: () => React.ReactNode
}) {
  return (
    <form>
      {renderHeader?.()}
      <Input />
      {renderFooter ? renderFooter() : <DefaultFooter />}
      {renderActions?.()}
    </form>
  )
}

// Usage is awkward and inflexible
return (
  <Composer
    renderHeader={() => <CustomHeader />}
    renderFooter={() => (
      <>
        <Formatting />
        <Emojis />
      </>
    )}
    renderActions={() => <SubmitButton />}
  />
)

Correct: compound components with children

function ComposerFrame({ children }: { children: React.ReactNode }) {
  return <form>{children}</form>
}

function ComposerFooter({ children }: { children: React.ReactNode }) {
  return <footer className='flex'>{children}</footer>
}

// Usage is flexible
return (
  <Composer.Frame>
    <CustomHeader />
    <Composer.Input />
    <Composer.Footer>
      <Composer.Formatting />
      <Composer.Emojis />
      <SubmitButton />
    </Composer.Footer>
  </Composer.Frame>
)

When render props are appropriate:

// Render props work well when you need to pass data back
<List
  data={items}
  renderItem={({ item, index }) => <Item item={item} index={index} />}
/>

Use render props when the parent needs to provide data or state to the child.

Use children when composing static structure.

4. React 19 APIs

Impact: MEDIUM

React 19+ only. Don't use forwardRef; use use() instead of useContext().

4.1 React 19 API Changes

Impact: MEDIUM (cleaner component definitions and context usage)

⚠️ React 19+ only. Skip this if you're on React 18 or earlier.

In React 19, ref is now a regular prop (no forwardRef wrapper needed), and use() replaces useContext().

Incorrect: forwardRef in React 19

const ComposerInput = forwardRef<TextInput, Props>((props, ref) => {
  return <TextInput ref={ref} {...props} />
})

Correct: ref as a regular prop

function ComposerInput({ ref, ...props }: Props & { ref?: React.Ref<TextInput> }) {
  return <TextInput ref={ref} {...props} />
}

Incorrect: useContext in React 19

const value = useContext(MyContext)

Correct: use instead of useContext

const value = use(MyContext)

use() can also be called conditionally, unlike useContext().

References

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by

Vercel

Publisher

JetBrains (Official)

Distributed by

JetBrains

Source

JetBrains/skills · composition-patterns · commit 3f53782

Licence

MIT License (redistribution allowed)

ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

AutoGineer is not affiliated with or endorsed by Vercel or JetBrains.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download vercel-composition-patterns.zip

From the author

AutoGineer summary

What it does

When to use it

Advantages

Usage examples

Install

Documentation by Vercel

React Composition Patterns

When to Apply

Rule Categories by Priority

Quick Reference

1. Component Architecture (HIGH)

2. State Management (MEDIUM)

3. Implementation Patterns (MEDIUM)

4. React 19 APIs (MEDIUM)

How to Use

Full Compiled Document

Files

AGENTS.md

React Composition Patterns

Abstract

Table of Contents

1. Component Architecture

1.1 Avoid Boolean Prop Proliferation

1.2 Use Compound Components

2. State Management

2.1 Decouple State Management from UI

2.2 Define Generic Context Interfaces for Dependency Injection

2.3 Lift State into Provider Components

3. Implementation Patterns

3.1 Create Explicit Component Variants

3.2 Prefer Composing Children Over Render Props

4. React 19 APIs

4.1 React 19 API Changes

References

Requirements and compatibility

Security

Attribution and licence

Related skills

Web Artifacts Builder

Frontend UI Engineering

Anti UI Slop

Ask Sonner

Pick UI Library

Animate Expo

Download ZIP