React Components 101: Building Reusable, Maintainable UI Pieces

A Familiar Scenario for Any Frontend Developer

Picture this: it's your first week at a new startup.

Your manager stops by your desk and tells you,

"The homepage needs to ship by Friday."

You pull up the Figma design.

It's made up of these sections:

• A top navigation menu
• A large hero banner
• A search bar area
• A showcase of featured products
• A section for customer testimonials
• A pricing table
• A frequently asked questions block
• A newsletter signup form
• A site footer

The task looks simple enough.

You spin up a single HTML file and start building each section in order.

By Friday, everything's done.

It all works fine.

You feel great about it.

Fast forward a month, and the product has grown.

The marketing team wants a fresh banner design.

The designers rework the navigation bar.

The product team wants an additional pricing tier section.

Customer reviews now need to load dynamically.

Before you know it, that one file has ballooned past 2,000 lines.

Locating a single button turns into a hunt through a maze of code.

Worse, tweaking one part of the page quietly breaks something else entirely unrelated.

Does this sound familiar?

This exact pain point is what pushed developers toward a different approach to building interfaces.

Rather than constructing one enormous page, what if you assembled it from many small, reusable pieces instead?

In React, these pieces are called Components.

Why a Single Giant File Falls Apart

Picture a typical webpage built the old way.

Homepage.html

---------------------------------------------------
Navigation
Hero Section
Featured Products
About Us
Testimonials
Pricing
FAQ
Newsletter
Footer
---------------------------------------------------

Every piece of the page lives inside that one file.

As the project scales up, you'll notice:

• The file keeps growing in size.
• Working as a team gets harder.
• Nothing can really be reused.
• Bugs start showing up more often.
• Maintaining the code becomes exhausting.

Now look at how React handles the same page.

App
│
├── Navbar
├── Hero
├── Products
│      ├── ProductCard
│      ├── ProductCard
│      └── ProductCard
├── Testimonials
├── FAQ
└── Footer

Rather than cramming everything into a single file, each section becomes its own self-contained unit.

This pattern is known as Component-Based Architecture.

Defining a React Component

At its core, a Component is nothing more than a reusable chunk of UI.

You can think of it as a JavaScript function that returns some JSX.

Rather than packing the whole page into a single file, you break it apart into smaller, focused pieces.

Each piece handles exactly one job.

For instance:

The navigation bar becomes its own component.

The footer is another component.

A product card is yet another.

A user profile section becomes one too.

You then assemble these components together to form the complete application.

The result is a codebase that's far easier to read, test, and keep up over time.

Shifting How You Think About UI

This is one of the most important mental shifts you'll go through as you pick up React.

Stop thinking in terms of entire pages.

Start thinking in terms of individual pieces.

Rather than asking:

"How should I build this homepage?"

Try asking:

"What smaller pieces come together to form this homepage?"

Once that shift clicks, React starts to feel much more intuitive.

An Everyday Comparison

Think about assembling a LEGO city.

You wouldn't mold a brand-new brick every single time you needed one.

Instead, you reach for bricks you already have.

Some bricks form walls.

Others become windows.

Others make up rooftops.

By mixing and matching these same reusable bricks, you can construct countless different buildings.

React Components function in exactly the same fashion.

A single Button component might show up:

• On the Login screen
• Inside a Modal window
• On the Checkout page
• Within the Navigation Bar

You build it a single time.

Then you drop it in wherever it's needed.

That's the real value Components bring.

The Reasoning Behind React's Component Model

React leans on Components because they address genuine, practical pain points.

1. Reusability

Build it once.

Reuse it endlessly.

Rather than recreating the same button code twenty separate times, you define a single Button component and plug it in anywhere it's needed across the app.

2. Readability

Consider two scenarios side by side.

One file stretching across 2,000 lines.

Versus...

Twenty separate files, each with a single, obvious purpose.

Which one would you rather come back to six months from now?

Smaller components are simply easier to reason about.

3. Maintainability

Picture a scenario where your company decides to rebrand its main button color.

If you hadn't split your UI into Components, that change would mean hunting down and editing dozens of files.

But with a single reusable Button component, you make the edit in one place.

Every screen that uses that button reflects the update instantly.

4. Team Collaboration

Picture five developers assigned to the same codebase.

One person handles the Navbar.

Another takes on the Hero section.

A third builds out Product Cards.

A fourth works on the Footer.

The fifth developer's job is to assemble all these pieces together.

Since each feature lives in its own component, nobody has to step on anyone else's work or wait around for a file to be free.

This kind of parallel workflow is exactly why Components matter so much in real-world development teams.

Functional Components

Today's React codebases rely almost entirely on Functional Components.

At its core, a Functional Component is nothing more than a JavaScript function that returns JSX.

Here's the most basic version you can write:

function Welcome() {
  return <h1>Hello, React!</h1>;
}

On the surface, this reads like an ordinary JavaScript function — because it is one.

What sets it apart is that instead of returning something like a number or a string, it hands back JSX, and React uses that JSX to figure out what to draw on screen.

Let's walk through it piece by piece:

function Welcome()

Here we're declaring a function called Welcome.

Pay attention to the capital "W" at the start of the name.

React specifically watches for that uppercase first letter to know a function should be treated as a Component.

Next comes this line:

return <h1>Hello, React!</h1>;

The function's job is to return JSX.

So any time React renders Welcome, this heading is what shows up.

That's the whole thing.

You've just built your first Component.

Creating Your First Component

Once a project starts to grow, developers usually give each component its own dedicated file.

A typical folder layout might look like this:

src
├── App.jsx
└── components
      └── Welcome.jsx

Here's what goes inside Welcome.jsx:

function Welcome() {
  return <h1>Welcome to React!</h1>;
}

export default Welcome;

Splitting components into their own files keeps your codebase tidy and much easier to navigate as it scales.

Exporting Components

You may be curious about the purpose of this line:

export default Welcome;

Say you've just written a solid, reusable component.

As long as it only lives inside its own file, nothing else in your app can reach it.

Exporting is what opens it up for use elsewhere.

It's a bit like publishing a manuscript.

Once it's out in the world, anyone can pick it up and read it.

The same logic applies here — once you export a component, any other file in your project can import it and put it to work.

There are other ways to export components, which we'll cover in a future part of this series, but export default is the go-to choice when you're getting started.

Importing Components

Let's bring Welcome into App.jsx and put it to use.

import Welcome from "./components/Welcome";

This line is essentially instructing React:

"Grab the Welcome component from this file so I can use it right here."

Once it's imported, rendering it takes almost no effort:

function App() {
  return (
    <>
      <Welcome />
    </>
  );
}

Take a closer look at this bit of syntax:

<Welcome />

Even though Welcome began life as a plain JavaScript function, we're able to use it just like a native HTML tag.

This is one of the more elegant parts of working with React — your custom functions turn into reusable building blocks for the interface.

How React Sees a Component

When React comes across this line:

<Welcome />

it isn't interpreting it as markup.

Instead, what's happening under the hood looks more like this:

Call the Welcome() function
↓
Receive JSX
↓
Convert JSX
↓
Update the Virtual DOM
↓
Render the UI

Put simply, every component boils down to a function call that hands back a chunk of the interface.

Once that idea clicks, Components stop feeling like some kind of special magic.

Naming Rules

There are a handful of naming conventions worth internalizing.

Names that work well:

• Navbar
• Footer
• Hero
• ProductCard
• UserProfile

Names to steer clear of:

• navbar
• footer
• component
• abc

What's the reasoning here?

React relies on capitalization as the signal that separates your custom Components from built-in HTML tags.

Take this example:

<Navbar />

React reads this as a reference to your own custom Component.

Compare that with:

<div>

which React interprets as a standard, built-in HTML element.

Choosing clear, descriptive names also pays off when other developers need to read and understand your code later.

Key Takeaways

Here's a quick recap of the ground covered so far.

• A Component is a self-contained, reusable chunk of UI.
• Building a React app really just means assembling and combining Components.
• Functional Components are plain JavaScript functions that return JSX.
• Breaking an app into Components pays off in readability, reusability, and long-term maintainability.
• A well-designed Component focuses on doing one thing.
• It's common practice to keep each Component in its own file and import it wherever it's needed.
• Capitalization is how React tells your custom Components apart from ordinary HTML elements.