vercel-labs / agent-skills

vercel-composition-patterns

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.

View source React Architecture

Install

npx skills add https://github.com/vercel-labs/agent-skills --skill vercel-composition-patterns

title: Define Generic Context Interfaces for Dependency Injection
impact: HIGH
impactDescription: enables dependency-injectable state across use-cases
tags: composition, context, state, typescript, dependency-injection

Define Generic Context Interfaces for Dependency Injection

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

Correct (generic interface enables dependency injection):

tsx

// Define a GENERIC interface that any provider can implementinterface 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:

tsx

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:

tsx

// Provider A: Local state for ephemeral formsfunction 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 channelsfunction 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:

tsx

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

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.

tsx

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

Design engineering

Frameworks & libraries

vercel-composition-patterns

Install

Define Generic Context Interfaces for Dependency Injection