Composing components

Real interfaces are never one big blob. A shopping page has a header, a search box, a list of product cards, each with an image, a title and a button, and a footer. In React you represent each of those pieces as a component and put them together like boxes inside boxes. This lesson shows how to think in components and how to nest them.

Thinking in components: draw boxes

Start from a design, a sketch or even a screenshot of a page you like. Draw a box around each part that has a clear job, and name it. A simple profile page might give:

ProfilePage
├── Header
│   ├── Logo
│   └── NavLinks
├── ProfileCard
│   ├── Avatar
│   ├── Name
│   └── Bio
└── Footer

Each name is a component. The nesting of the boxes becomes the nesting of the components. This diagram is a component tree, and App is its root. You do not have to decide the perfect tree up front. Build the page in one component first, then split pieces off as the code grows. Moving JSX into a new component is a mechanical change, and the page looks the same afterwards.

Nesting components

A component uses another by writing its tag. Here is a small page built from parts:

function Header() {
  return (
    <header>
      <strong>MySite</strong> | <a href="#home">Home</a> <a href="#about">About</a>
    </header>
  );
}

function Avatar() {
  return <span aria-hidden="true">🙂</span>;
}

function ProfileCard() {
  return (
    <section>
      <Avatar />
      <h2>Asha Rao</h2>
      <p>Front-end developer from Pune.</p>
    </section>
  );
}

function Footer() {
  return <footer><small>© 2026 MySite</small></footer>;
}

function App() {
  return (
    <div>
      <Header />
      <ProfileCard />
      <Footer />
    </div>
  );
}

export default App;

MySite | Home About
🙂
Asha Rao
Front-end developer from Pune.
© 2026 MySite

Follow what happens when React renders this. It calls App, which returns a div containing <Header />, <ProfileCard /> and <Footer />. React then calls each of those in turn. ProfileCard returns a section that contains <Avatar />, so React calls Avatar as well. The final page is the combination of all the returned elements. Rendering always flows from the root down through the tree.

Notice that App now reads like an outline of the page. That is the second benefit of components after reuse: readability. Someone opening App sees the structure in five lines and can jump into whichever part they need.

Order in the file does not matter

In the example, App is last and uses components defined above it, but the order is not required. Function declarations are available throughout the file, and React only calls them when it renders. Most people put the main component at the bottom or top. In real projects each component is in its own file anyway and is imported where used.

The same component in different places

Because components are reusable, you can place one anywhere in the tree, any number of times:

function Star() {
  return <span style={{ color: "#e0a800" }}>★</span>;
}

function Rating() {
  return (
    <span>
      <Star /><Star /><Star /><Star /><Star />
    </span>
  );
}

function Review() {
  return (
    <article>
      <h3>Great course</h3>
      <Rating />
      <p>Clear lessons and good examples.</p>
    </article>
  );
}

function App() {
  return (
    <div>
      <Review />
      <Review />
    </div>
  );
}

export default App;

Great course
★★★★★
Clear lessons and good examples.
Great course
★★★★★
Clear lessons and good examples.

Star appears five times inside Rating, and Rating appears once in each Review. React renders ten stars in total. Every one of them is a separate instance. The data is identical for now; in the next lesson, props will let each instance show different content (a different rating, a different review).

When to extract a component

Splitting is a judgement call. Good reasons:

• Repetition. You copy the same markup in several places, or a list item has the same shape every time.
• A clear name. If you can say "this is the order summary", it deserves to be OrderSummary.
• Size. A component with hundreds of lines is hard to read; split by purpose.
• Separate responsibilities. A piece with its own state or its own logic, such as a search box, is easier to understand on its own.
• Testing and reuse. A small component is easy to check in isolation and to use on another page.

Poor reasons: splitting every <div> into a component, or creating a component used once that has no meaningful name. Too many tiny components scatter simple code across files and make it harder to follow. A good habit is to extract when the code starts to feel crowded, not before.

Component tree and data

In React, data flows down the tree: a parent passes information to its children, and not the other way around. When two siblings need the same data, it lives in their common parent. This one-way flow is why you can trace where a value comes from: look upward in the tree. The next lessons cover how a parent passes data (props) and, later, how a child asks the parent to change something (callbacks and state lifted up).

A larger composition: a layout component

Components can wrap other content, like a frame. This preview of the next lessons shows a Card component that accepts whatever you put between its tags (the children):

function Card({ children }) {
  return (
    <div style={{ border: "1px solid #999", borderRadius: 8, padding: 12, margin: "8px 0" }}>
      {children}
    </div>
  );
}

function App() {
  return (
    <div>
      <Card>
        <h3>First card</h3>
        <p>Any content can go inside.</p>
      </Card>
      <Card>
        <p>A second card with just a paragraph.</p>
      </Card>
    </div>
  );
}

export default App;

First card
Any content can go inside.
A second card with just a paragraph.

Don't worry about the { children } syntax yet. It is covered in The children prop and prop patterns. What matters here is the idea: one component can provide a frame, and others fill it.

Common mistakes

• Putting everything in one giant App and never extracting anything.
• Over-splitting into dozens of one-line components with no meaningful names.
• Naming a component after its position (LeftBox) instead of its purpose (FilterPanel).
• Expecting a child to change its parent's data directly. Data flows down; a later lesson shows how children ask for changes.
• Forgetting to close tags of custom components (<Header> without / or a closing tag).

Exercise

1. Add a Contact component with an email address to the profile page, and place it inside ProfileCard.
2. Make Rating show three stars, and add a third Review to App.
3. Draw a component tree on paper for a web page you use every day (a news site, a video site). Name at least eight components.
4. Take the Card example and wrap each card's content in a smaller component of your choice.