ring-applying-composition-patterns

name	ring:applying-composition-patterns
description	React composition patterns that scale. Avoid boolean prop proliferation by using compound components, lifting state, and composing internals. Use when refactoring components with boolean prop proliferation, building flexible component libraries, or during architecture review. Skip for simple components with 1-2 props or non-React code.
paths	["**/*.tsx","**/*.jsx"]

Applying Composition Patterns

When to use

• Refactoring components with boolean prop proliferation
• Building flexible, reusable component libraries
• Architecture review of React component hierarchies
• Component has grown to 3+ boolean props controlling behavior
• Multiple render props or conditional rendering branches

Skip when

• Simple components with 1-2 props and no conditional rendering
• Non-React code
• Prototype or throwaway code where flexibility doesn't matter
• Component is leaf-level with no composition concerns

Related

Complementary: ring:checking-frontend-quality — validate component quality after refactoring

---

Abstract

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.

---

Table of Contents

1. Component Architecture — HIGH
   • 1.1 Avoid Boolean Prop Proliferation
   • 1.2 Use Compound Components
2. 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
3. Implementation Patterns — MEDIUM
   • 3.1 Create Explicit Component Variants
   • 3.2 Prefer Composing Children Over Render Props
4. 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

const 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
const 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
const 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
const 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

const 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)

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

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

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

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

// Export as compound component
const Composer = {
  Provider: ComposerProvider,
  Context: ComposerContext, // exported for external consumers (e.g. buttons outside Frame)
  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

const 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
const 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
const ChannelComposer = () => {
  return (
    <Composer.Frame>
      <Composer.Header />
      <Composer.Input />
      <Composer.Footer>
        <Composer.Submit />
      </Composer.Footer>
    </Composer.Frame>
  )
}

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

Different providers, same UI:

// Local state for ephemeral forms
const 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
const 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

const 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:

const 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
const 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
const 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:

const 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>
  )
}

// ComposerContext is exported from the Composer module for external consumers
// This button lives OUTSIDE Composer.Frame but can still submit based on its context!
const ForwardButton = () => {
  const {
    actions: { submit }
  } = use(ComposerContext)
  return <Button onPress={submit}>Forward</Button>
}

// This preview lives OUTSIDE Composer.Frame but can read composer's state!
const 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

const 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?
const ForwardMessageDialog = () => {
  return (
    <Dialog>
      <ForwardMessageComposer />
      <MessagePreview /> {/* Needs composer state */}
      <DialogActions>
        <CancelButton />
        <ForwardButton /> {/* Needs to call submit */}
      </DialogActions>
    </Dialog>
  )
}

Incorrect: useEffect to sync state up

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

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

Incorrect: reading state from ref on submit

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

Correct: state lifted to provider

const 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>
  )
}

const ForwardMessageDialog = () => {
  return (
    <ForwardMessageProvider>
      <Dialog>
        <ForwardMessageComposer />
        <MessagePreview />
        <DialogActions>
          <CancelButton />
          <ForwardButton />
        </DialogActions>
      </Dialog>
    </ForwardMessageProvider>
  )
}

const 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:

const 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>
  )
}

const 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>
  )
}

const 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

const 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

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

const 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. Prefer ref as a regular prop over forwardRef; prefer use() over useContext() for new components.

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 a regular prop (making forwardRef unnecessary for new components), and use() is the preferred alternative to useContext(). Both forwardRef and useContext still work but are discouraged in new code.

Incorrect: forwardRef in React 19

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

Correct: ref as a regular prop

const 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

1. https://react.dev
2. https://react.dev/learn/passing-data-deeply-with-context
3. https://react.dev/reference/react/use