🧩 Component Composition Patterns

What Is Composition?

Component composition is the practice of building complex interfaces by combining smaller, single-purpose components. Instead of one giant component that knows everything, you assemble a tree of focused pieces — each doing one job well and handing off the rest to its neighbors.

💡 A useful analogy: Composition is like building with LEGO. Each brick is dumb on its own, but the studs-and-sockets connection is standardized, so you can snap bricks together in endless combinations. In React, the "stud" is the children prop and the "socket" is the JSX you nest inside a component.

Every non-trivial React app is a composition tree. A page is made of sections, sections of cards, cards of buttons and text. The skill you're building here is designing components whose "sockets" are in the right places so the pieces snap together cleanly.

Composition vs. Inheritance

In many object-oriented languages you'd share UI by extending a base class. React deliberately steers you away from that. The official guidance is blunt: use composition instead of inheritance to reuse code between components.

Why? Inheritance couples a child to the exact shape of its parent. Change the base and every subclass can break. Composition couples components only through props — a narrow, explicit contract. The benefits stack up:

• Reusability — a well-composed component drops into many contexts unchanged.
• Separation of concerns — each component owns one responsibility.
• Maintainability — small components are easier to read, test, and refactor.
• Flexibility — callers combine pieces in ways you never anticipated.

🏭 Real-world analogy: Think of a car assembly line. No one builds a whole car in one step. Specialized teams produce the engine, the transmission, the body panels — each tested independently — and the line assembles them. The same engine ships in three different models. That reuse is only possible because the parts connect through standard interfaces, not because one part inherits from another.

The Containment Pattern (children)

Some components don't know their children ahead of time — dialogs, cards, sidebars, layout shells. These "generic boxes" use the special children prop to render whatever JSX the caller nests inside them, exactly like a built-in <div> does.

A reusable Card component

// Card.jsx
function Card({ title, children }) {
  return (
    <div className="card">
      {title && <div className="card-header">{title}</div>}
      <div className="card-body">{children}</div>
    </div>
  );
}

// Usage — the Card owns structure & style; the caller owns content
function App() {
  return (
    <>
      <Card title="User Profile">
        <h3>Jane Doe</h3>
        <p>Software Engineer</p>
        <button>View Profile</button>
      </Card>

      <Card title="Weather">
        <h3>San Francisco</h3>
        <p>68°F, Partly Cloudy</p>
      </Card>
    </>
  );
}

The Card is responsible for the frame — padding, border, header styling — while the content stays entirely in the caller's hands. One component, unlimited uses.

Every major component library — Material UI, Chakra UI, Radix, shadcn/ui — leans on containment for its cards, dialogs, and layout primitives. It is the workhorse pattern of React composition.

Slots: Multiple Named Holes

Sometimes one children hole isn't enough. A page layout might need a distinct header, sidebar, and content region. Because JSX elements are just values, you can pass entire chunks of UI through ordinary props — the React equivalent of "named slots."

function SplitLayout({ sidebar, children }) {
  return (
    <div className="split">
      <aside className="split-sidebar">{sidebar}</aside>
      <main className="split-main">{children}</main>
    </div>
  );
}

// Each slot receives its own tree of JSX
function App() {
  return (
    <SplitLayout sidebar={<NavMenu items={links} />}>
      <Dashboard />
    </SplitLayout>
  );
}

Here sidebar is a slot filled with a whole <NavMenu>, while children holds the main area. This keeps SplitLayout layout-only and completely ignorant of what goes in each region.

Compound Components

The most powerful composition pattern is the compound component: a family of components designed to work together, sharing implicit state through React Context. The classic example is a set of tabs. The caller writes clean, declarative markup; the components coordinate behind the scenes.

import { createContext, useContext, useState } from 'react';

const TabsContext = createContext(null);

function Tabs({ defaultTab, children }) {
  const [activeTab, setActiveTab] = useState(defaultTab);
  return (
    <TabsContext.Provider value={{ activeTab, setActiveTab }}>
      <div className="tabs">{children}</div>
    </TabsContext.Provider>
  );
}

function useTabs() {
  const ctx = useContext(TabsContext);
  if (!ctx) throw new Error('Tab components must be used inside <Tabs>');
  return ctx;
}

function TabList({ children }) {
  return <div className="tab-list" role="tablist">{children}</div>;
}

function Tab({ value, children }) {
  const { activeTab, setActiveTab } = useTabs();
  const selected = activeTab === value;
  return (
    <button
      role="tab"
      aria-selected={selected}
      className={selected ? 'tab active' : 'tab'}
      onClick={() => setActiveTab(value)}
    >
      {children}
    </button>
  );
}

function TabPanel({ value, children }) {
  const { activeTab } = useTabs();
  if (value !== activeTab) return null;
  return <div role="tabpanel" className="tab-panel">{children}</div>;
}

// Expose the family as properties of the parent for a clean namespace
Tabs.List = TabList;
Tabs.Tab = Tab;
Tabs.Panel = TabPanel;

export default Tabs;

Now the usage reads almost like plain HTML — no wiring, no manual state plumbing:

function Settings() {
  return (
    <Tabs defaultTab="profile">
      <Tabs.List>
        <Tabs.Tab value="profile">Profile</Tabs.Tab>
        <Tabs.Tab value="account">Account</Tabs.Tab>
        <Tabs.Tab value="alerts">Alerts</Tabs.Tab>
      </Tabs.List>

      <Tabs.Panel value="profile"><ProfileForm /></Tabs.Panel>
      <Tabs.Panel value="account"><AccountForm /></Tabs.Panel>
      <Tabs.Panel value="alerts"><AlertSettings /></Tabs.Panel>
    </Tabs>
  );
}

Render Props & Function Children

What if a component owns some behavior — tracking the mouse, watching a media query, managing a toggle — but shouldn't dictate how that behavior is displayed? The render-props pattern solves this by letting children be a function that receives the state and returns the UI.

import { useState } from 'react';

// Owns "open/closed" behavior; renders nothing itself
function Toggle({ children }) {
  const [on, setOn] = useState(false);
  const toggle = () => setOn(prev => !prev);
  return children({ on, toggle });
}

// The caller decides exactly how to render the state
function App() {
  return (
    <Toggle>
      {({ on, toggle }) => (
        <>
          <button onClick={toggle}>{on ? 'Hide' : 'Show'} details</button>
          {on && <p>Here are the details!</p>}
        </>
      )}
    </Toggle>
  );
}

Hands-on: A Composable Modal

function Modal({ isOpen, onClose, children }) {
  if (!isOpen) return null;
  return (
    <div className="modal-backdrop" onClick={onClose}>
      <div className="modal-content" onClick={(e) => e.stopPropagation()}>
        {children}
      </div>
    </div>
  );
}
// TODO: add Modal.Header, Modal.Body, Modal.Footer

function Modal({ isOpen, onClose, children }) {
  if (!isOpen) return null;
  return (
    <div className="modal-backdrop" onClick={onClose}>
      <div
        className="modal-content"
        role="dialog"
        aria-modal="true"
        onClick={(e) => e.stopPropagation()}
      >
        {children}
      </div>
    </div>
  );
}

Modal.Header = function Header({ children }) {
  return <div className="modal-header">{children}</div>;
};
Modal.Body = function Body({ children }) {
  return <div className="modal-body">{children}</div>;
};
Modal.Footer = function Footer({ children }) {
  return <div className="modal-footer">{children}</div>;
};

// Usage
function ConfirmDialog({ open, onClose, onConfirm }) {
  return (
    <Modal isOpen={open} onClose={onClose}>
      <Modal.Header><h2>Delete project?</h2></Modal.Header>
      <Modal.Body><p>This action cannot be undone.</p></Modal.Body>
      <Modal.Footer>
        <button onClick={onClose}>Cancel</button>
        <button className="danger" onClick={onConfirm}>Delete</button>
      </Modal.Footer>
    </Modal>
  );
}

Best Practices

Summary & Quiz

📚 Further Reading

• React docs — Passing JSX as children
• React docs — Passing data deeply with Context
• Kent C. Dodds — Compound components with React Hooks

🚀 What's Next?

You've seen how components fit together. Next we'll extract the logic those components share into reusable custom hooks — the modern answer to the render-props question we raised above.