Component Composition and Children

There is a moment in every growing React for Beginners project when a wrapper component multiplies its props: Card grows title, subtitle, image, footer, actions… until it knows everything about its contents. The escape hatch has always been there — props.children. This chapter covers the children prop, slot-style composition, and why combining small components beats configuring one big one.

The children prop

Anything you nest between a component's tags arrives automatically as props.children. The wrapper does not need to know what it is wrapping:

function Card({ children }) {
  return <div className="card">{children}</div>;
}

function App() {
  return (
    <Card>
      <h2>Monthly report</h2>
      <p>Revenue grew 12%</p>
      <button>Export</button>
    </Card>
  );
}

Expected output: a card containing a heading, paragraph and button — passed in as markup, not as props. The Card never changes when its contents do; it owns presentation only.

Slots: named pieces of content

When a wrapper needs structure with several holes, pass elements through named props instead of inventing data props. Each prop holds JSX, so the parent controls what goes in each slot:

function Layout({ header, sidebar, children }) {
  return (
    <div className="layout">
      <header>{header}</header>
      <aside>{sidebar}</aside>
      <main>{children}</main>
    </div>
  );
}

// Usage
<Layout
  header={<NavBar />}
  sidebar={<Filters />}
>
  <ResultsTable />
</Layout>

Expected output: a three-region page where each region is supplied as an element by the caller — the layout constrains structure, the caller supplies content.

Composition vs configuration

The choice between "many props" and "children/slots" is really a choice between two design styles:

A practical rule: if a prop expects markup, it should probably accept an element (or be a child). If it expects data or a choice — colour, size, count — a plain prop is right.

Extracting components as composition

Composition is also how you fight oversized JSX. When a return value grows past a screenful, split it — each piece becomes testable and reusable:

function ProfilePage({ user }) {
  return (
    <Page>
      <ProfileHeader user={user} />
      <ProfileStats stats={user.stats} />
      <ProfileFeed posts={user.posts} />
    </Page>
  );
}

Expected output: the same rendered page, now built from four readable components — each with a single job. The parent reads like a table of contents, and you can swap ProfileFeed for something else without touching the header.

Controlled visibility: the modal pattern

Composition shines for one-off UI: a Modal that renders whatever you give it, controlled by the parent's state. The wrapper handles positioning and the overlay; the parent decides the content and when it opens:

const [open, setOpen] = useState(false);

<button onClick={() => setOpen(true)}>Delete</button>
<Modal open={open} onClose={() => setOpen(false)}>
  <h2>Are you sure?</h2>
  <button onClick={confirmDelete}>Yes, delete</button>
</Modal>

Expected output: the modal's chrome is written once; each usage supplies its own body. Note that children may be a single element or an array — React normalises both, so callers can nest anything.

Display names and debugging

Composed trees show up in the React DevTools and error messages. Name your components clearly (a wrapper that only adds layout can be Panel, not Wrapper2) so a stack trace points at the right file. For truly generic helpers, setting Component.displayName helps tools label anonymous functions.

Common mistakes

• Passing children and a conflicting prop — <Card title="A">…</Card> when Card renders both is confusing; pick one convention.
• Configuring instead of composing — a wrapper with eight optional element props should accept children or slots instead.
• Cloning children to inject props — cloneElement on children is brittle; pass an explicit prop or a render function instead.
• Huge anonymous JSX — refusing to extract components until nobody can read the file; split at the first screenful.
• Wrapping for no reason — a div-per-div "component" adds files without adding meaning; compose only where structure or reuse is real.

Practice checklist

1. Build a Card that accepts children and render three different bodies through it.
2. Create a Layout with header/sidebar/main slots and fill each with a real component.
3. Refactor one long return value into three extracted components.
4. Write a Modal driven by parent state with a close callback.
5. Audit a prop that expects markup and convert it to an element slot.

Composition keeps structure clean — the next chapter tackles data that the whole tree needs: Managing Global State with Context.