Organizing React Components

In the last lesson you learned how to build Reusable React Components. But as you keep adding components, where do you actually put them all? This lesson covers the simple habits that keep a growing project easy to work in.

🤔 Why Organizing Matters

Think about a kitchen. If every spoon, plate, and pan is thrown into one drawer, finding anything takes forever. Code is the same. A messy project still works, but every small change feels like a chore.

Here is the pain, and then the fix.

• You open a file and there are five components stacked in it. You scroll up and down just to find the one you want. So the fix is one component per file.
• A file is named comp1.jsx and you have no idea what is inside. The fix is naming the file after the component.
• You have forty component files in one flat folder. The fix is grouping related files into folders.

None of this changes how React runs. See, it changes how you feel while working. And on a real team, organized code lets other people read your work without asking you a hundred questions.

🧩 One Component Per File

The first habit is simple. Each component gets its own file. So a Button component lives in Button.jsx, and nothing else lives there.

Here is what to avoid, and what to do instead.

// ❌ Avoid: many components crammed into one file
function Button() {
  return <button>Click me</button>;
}

function Header() {
  return <h1>Welcome</h1>;
}

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

That file mixes three unrelated things. When you want to fix the footer, you scroll past the button and the header first.

// ✅ Good: one component, one file
export default function Button() {
  return <button>Click me</button>;
}

Now Button lives alone in Button.jsx. Here is what is going on.

• The Header and Footer get their own files too, so Header.jsx and Footer.jsx.
• Each file holds one component, and export default makes it available to the rest of the app.
• When you need the button, you open the file literally called Button.jsx. No scrolling, no hunting.
• And when you change that file, you know you are only touching the button and nothing else.

🏷️ Name the File After the Component

The second habit goes with the first. Here is the rule.

• The file name should match the component name, so a component called UserCard goes in a file called UserCard.jsx. Same word, same casing.
• Component names use PascalCase, which means every word starts with a capital letter and there are no spaces, like UserCard or NavBar.
• This matters because React treats lowercase and capitalized names differently. A tag like <userCard /> is read as a plain HTML tag, but <UserCard /> is read as your component.
• So keeping the file name capitalized too keeps everything consistent.

This table shows the pattern clearly.

When the file name and the component name are the same word, your import line reads like plain English. You write import UserCard from "./UserCard" and there is zero guessing about what you just brought in.

📁 Group Related Components Into Folders

Once you have a handful of files, drop them all into one folder so they are not mixed in with everything else. The usual home is a folder called components.

Here is a small project that keeps every component together.

src/
├── components/
│   ├── Button.jsx
│   ├── Header.jsx
│   ├── Footer.jsx
│   └── UserCard.jsx
├── App.jsx
└── main.jsx

The thing to notice is that all your reusable pieces sit in components/. Your App.jsx stays at the top and pulls them in. So when you go looking for a piece of UI, you already know which folder to open.

This works great for a small project. But what happens when you have fifty components? A flat components/ folder starts feeling crowded again, and that is when you group by feature.

A feature folder is a folder named after a part of your app, like profile or cart, holding all the components for just that part. Here is the same idea at a bigger scale.

src/
├── components/
│   ├── ui/
│   │   ├── Button.jsx
│   │   └── Input.jsx
│   ├── profile/
│   │   ├── UserCard.jsx
│   │   └── Avatar.jsx
│   └── cart/
│       ├── CartItem.jsx
│       └── CartTotal.jsx
├── App.jsx
└── main.jsx

Here is how that splits up.

• Shared building blocks like Button and Input live in ui/, while everything about the profile lives in profile/.
• Each folder is one area of the app, and the components inside it belong to that area.
• So a teammate working on the cart only opens the cart/ folder and ignores the rest.

✂️ When to Split a Big Component

Sometimes the problem is not where files live. It is that one component has grown too big. Picture a ProfilePage that shows the avatar, the user details, the friend list, and the recent posts, all in one file. It works, but it is hard to read and hard to change.

Watch for these signs that it is time to split.

• The component is so long you have to scroll a lot to read it.
• You can point at a chunk and give it a clear name, like “this part is the avatar”.
• You find yourself wanting to reuse one part somewhere else.
• You copy and paste the same block of JSX more than once.

When that happens, pull each clear chunk into its own smaller component. The big ProfilePage then just arranges the smaller pieces.

import Avatar from "./Avatar";
import UserDetails from "./UserDetails";
import FriendList from "./FriendList";

export default function ProfilePage() {
  return (
    <div className="profile-page">
      <Avatar />
      <UserDetails />
      <FriendList />
    </div>
  );
}

Read the code first, then the why.

• ProfilePage imports three smaller components and puts them on the page in order.
• Each small piece, like Avatar, lives in its own file and worries about only its own job.
• So the big component reads like a table of contents now. You glance at it and see the page is an avatar, then details, then a friend list.
• If the friend list breaks, you open FriendList.jsx and stay focused on just that.

🔤 Use Clear Names

The last habit ties everything together. A name should say what the component is or does. Someone reading OrderSummary knows what it shows without opening it. Someone reading Comp2 learns nothing.

Here is the difference in practice.

// ❌ Avoid: vague names that hide meaning
function Box1() { /* ... */ }
function Thing() { /* ... */ }

// ✅ Good: names that describe the job
function SearchBar() { /* ... */ }
function ProductCard() { /* ... */ }

The good names read almost like a sentence. You see SearchBar and ProductCard and you already have a picture in your head. Clear names mean less time spent opening files just to remember what they do.

⚠️ Common Mistakes

A few mistakes catch almost everyone when they start organizing.

• Many components in one file. It feels faster at first, but it slows you down later. Give each component its own file.
• File name does not match the component. A file called index2.jsx holding UserCard makes imports confusing. Match the file name to the component name.
• lowercase component names. React treats <usercard /> as an HTML tag, so it will not render your component. Always start component names with a capital letter.
• Folders so deep you get lost. Five levels of nested folders is its own kind of mess. Keep the structure shallow and only add folders when you truly need them.
• Organizing too early. Building ten folders for a three-component app wastes time. Let the structure grow with the project.

✅ Best Practices

• Keep one component per file and name the file after the component.
• Use PascalCase for both component names and their file names.
• Start with a flat components/ folder, then move to feature folders only when it gets crowded.
• Split a component when it gets too long or you spot a clear, reusable chunk inside it.
• Pick names that describe what the component shows or does, so the name does the explaining for you.

🧩 What You’ve Learned

• ✅ Why keeping components organized makes a growing project easier to work in.
• ✅ Put one component per file, and name the file after the component.
• ✅ Use PascalCase for component names and their file names.
• ✅ Group related components into a components/ folder, then into feature folders as the project grows.
• ✅ Split a big component into smaller ones when it gets too long or has a clear, reusable part.
• ✅ Choose clear, descriptive names so the name explains the component on its own.

🚀 What’s Next?

You now know how to keep your components tidy as your project grows. Next up is the tool that lets components talk to each other and pass data around, which is where the pieces start working together.

React Props