The Compound Components Pattern

The plain-language idea

A compound component is a set of components designed to be used together, where the parent manages shared state and the children read it implicitly instead of receiving it as explicit props. <select> and <option> in plain HTML already work this way — you never wire <option> to <select> yourself, the browser does it because they're built to cooperate. React's version of that trick uses Context internally, but hides it completely from whoever's using the component.

The payoff is the calling code. Compare a Tabs API that takes a config array:

<Tabs
  items={[
    { id: "a", label: "Profile", content: <Profile /> },
    { id: "b", label: "Settings", content: <Settings /> },
  ]}
/>

against one written as compound components:

<Tabs defaultTab="a">
  <TabList>
    <Tab id="a">Profile</Tab>
    <Tab id="b">Settings</Tab>
  </TabList>
  <TabPanel id="a"><Profile /></TabPanel>
  <TabPanel id="b"><Settings /></TabPanel>
</Tabs>

The second reads like markup, lets the caller reorder, conditionally render, or interleave arbitrary JSX between tabs, and never forces the shared state into a props object at all.

See it in a real thing: Tabs sharing state through Context

const TabsContext = createContext(null);

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

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

function Tab({ id, children }) {
  const { activeId, setActiveId } = useContext(TabsContext);
  return (
    <button
      className={id === activeId ? "tab active" : "tab"}
      onClick={() => setActiveId(id)}
    >
      {children}
    </button>
  );
}

function TabPanel({ id, children }) {
  const { activeId } = useContext(TabsContext);
  return activeId === id ? <div className="tab-panel">{children}</div> : null;
}

Tabs.List = TabList;
Tabs.Tab = Tab;
Tabs.Panel = TabPanel;

Tabs owns activeId and hands it to TabsContext. Neither Tab nor TabPanel receives activeId as a prop from their caller — they each pull it straight from context, which is what makes them "implicitly" connected. Attaching Tab and TabPanel onto Tabs as static properties (Tabs.Tab, Tabs.Panel) is a common convention that signals "these only make sense inside a Tabs," without actually enforcing it at compile time.

What people usually miss

Watch out

• This is Context solving a different problem than prop drilling. The Context lesson covers passing a value down through many unrelated layers; here Context is used one level deep, purely so siblings (Tab, TabPanel) can implicitly coordinate without their parent (Tabs) manually wiring props between them.
• The pieces aren't independently reusable — that's intentional. Tab only works inside a Tabs provider. This is a deliberate tradeoff: you give up standalone reusability of the pieces in exchange for a much cleaner API at the call site.
• The Tabs.Tab static-property convention is sugar, not enforcement. Nothing stops someone from importing Tab directly and rendering it outside Tabs — the null-context guard in the callout is the actual safety net, the namespacing is just discoverability.
• This pattern is common in real UI libraries, not just a teaching example — accordions, menus, and radio groups in most component libraries are built exactly this way, so recognizing the shape helps you read their source, not just build your own.

The genealogy: Context, redirected inward

This is the same Context mechanism the Context lesson introduces for skipping prop drilling across distant layers — but redirected to solve implicit coordination between direct siblings instead. The provider and consumers here are typically only one level apart; the value being shared isn't a global concern like theme or auth, it's private state that only this specific family of components should ever read.