Component composition patterns

01Explain it simply

Composition means building complex UI by combining smaller components, rather than one component trying to handle every variation through props. children, render props, and compound components — like Tabs.List and Tabs.Panel — are three ways to let a parent component stay flexible about what it renders without knowing the specifics upfront.

One-line definition: Share behavior across components with children, render props, and compound components instead of prop-drilling or duplication.

02Mental model

The core question every pattern answers is: who decides what renders, and who owns the shared state? children lets the parent stay completely agnostic about content. A render prop lets the parent own state and logic while the consumer decides the exact markup. Compound components split into several linked pieces that implicitly share state through context, giving a JSX-composition-friendly API instead of one component with dozens of props.

03Step by step

• Check whether a growing prop list — renderHeader, renderFooter, showX, showY — is really a composition problem in disguise.
• Use children when the parent doesn't need to know anything about what's inside.
• Use a render prop or hook when the parent owns logic and state but the consumer needs to control rendering.
• Use compound components with context when several related pieces need to share implicit state.
• Prefer a custom hook over a wrapper component when there's no UI structure to compose, only logic to share.

04Working example

1// Compound component: shared state via context, flexible JSX composition2const TabsContext = createContext(null);3
4function Tabs({ children, defaultValue }) {5  const [value, setValue] = useState(defaultValue);6  return <TabsContext.Provider value={{ value, setValue }}>{children}</TabsContext.Provider>;7}8Tabs.List = function TabsList({ children }) { return <div role="tablist">{children}</div>; };9Tabs.Tab = function Tab({ value: tabValue, children }) {10  const { value, setValue } = useContext(TabsContext);11  return <button aria-selected={value === tabValue} onClick={() => setValue(tabValue)}>{children}</button>;12};

Tabs owns the selected-tab state once; Tabs.List and Tabs.Tab read and update it through context instead of receiving it via props threaded down manually. The consumer composes the pieces freely, reordering or wrapping them without the parent needing new props for every layout variant.

05Where it is used

• Design-system components like Tabs, Accordion, or Select that have several related sub-parts
• Sharing data-fetching logic across differently-rendered UIs via a render prop or hook
• Layout components such as Modal or Card that shouldn't need to know their contents
• Replacing a component with a dozen boolean or render* props with a composable API

06Common mistakes

• Growing a component's prop list indefinitely instead of recognizing a composition problem
• Building compound components without context, forcing awkward manual prop-threading between the pieces
• Reaching for a render prop when a plain custom hook would share the same logic more simply
• Over-engineering composition for a component that only ever renders one way in practice

07Interview answer

Frame the choice around who owns state versus who owns markup — that's the actual decision compound components, render props, and children all resolve differently, and naming it shows deeper understanding than listing pattern names.