React Organizing Components

In the last lesson, React Folder Structure, you set up the project’s folders. Now let’s tidy the components themselves so you don’t end up with huge, do-everything pieces that are hard to read, reuse, and test.

🤔 Why does organizing components matter?

Here’s the pain. As components grow, they turn into tangled monsters that do too much.

• One component fetches data, holds state, handles events, and renders a big chunk of UI.
• It’s hard to read, because you have to understand everything at once.
• It’s hard to reuse, because the display is tangled up with specific logic.
• It’s hard to test, because there’s no clean piece to test on its own.

So organizing components is about keeping each one small with a clear single job.

🧩 Keep components small and focused

The first rule is the most important: each component should do one clear thing.

• If a component is hundreds of lines, it’s probably doing several jobs. Split it.
• A good component has one clear responsibility, like “show a user card” or “handle the login form”.
• Smaller components are easier to name, reuse, and understand at a glance.

So when a component feels too big or hard to name, that’s your signal to break it into smaller pieces.

🎭 Split presentational and container components

A classic, useful split is separating how it looks from how it works.

• A presentational component just shows UI from its props. No data fetching, no complex logic.
• A container component handles the logic: fetching data, holding state, and passing it down.
• So the container is the brain, and the presentational component is the face.

// presentational: just shows what it's given
function UserCard({ name, email }) {
  return (
    <div className="card">
      <h3>{name}</h3>
      <p>{email}</p>
    </div>
  );
}

// container: handles the logic, then uses the presentational component
function UserCardContainer({ userId }) {
  const { data } = useFetch(`/api/users/${userId}`);
  if (!data) return <p>Loading...</p>;
  return <UserCard name={data.name} email={data.email} />;
}

Read what each does.

• UserCard only takes name and email and renders them. So it’s simple and reusable anywhere.
• UserCardContainer does the fetching and loading logic, then hands clean data to UserCard.
• So you can reuse UserCard with any data source, and test it just by passing props.

📦 Co-locate related files

Keep the files that belong to a component close to it, not scattered across the project.

components/
  UserCard/
    UserCard.jsx
    UserCard.module.css
    UserCard.test.jsx

Why this helps.

• The component, its styles, and its test sit together in one folder.
• To work on UserCard, you open one folder and everything’s there.
• Moving or deleting the component means moving or deleting one folder.

So co-location keeps a component easy to find, change, and remove as a unit.

🏷️ Name and export clearly

Clear names and one component per file keep things predictable.

• Use PascalCase for component names and files, like UserCard.jsx.
• Put one main component per file, named the same as the file.
• Name components for what they are, like LoginForm or ProductList, not vague names like Thing or Box2.

So when you see LoginForm.jsx, you know exactly what’s inside.

⚠️ Common Mistakes

The biggest mistake is the giant component that does everything.

// ❌ one component fetching, holding state, AND rendering a huge UI - hard to manage
function Dashboard() {
  // 200 lines of fetching, state, handlers, and JSX all mixed together
}

// ✅ split into focused pieces
function Dashboard() {
  return (
    <>
      <StatsPanel />
      <RecentActivity />
      <UserList />
    </>
  );
}

Keep these in mind.

• Don’t let a component grow into a monster. Split it when it does several jobs.
• Don’t tangle display and logic when separating them would make both clearer.
• Don’t use vague names. A component’s name should say what it does.

✅ Best Practices

A few habits for organizing components.

• Keep each component small and focused on one clear job.
• Separate presentational (display) from container (logic) when it makes both cleaner.
• Co-locate a component with its styles and test in one folder.
• Use clear PascalCase names, one main component per file.

🧩 What You’ve Learned

• ✅ Keep each component small and focused on one clear responsibility
• ✅ Split presentational components (display from props) from container components (logic and data)
• ✅ Presentational pieces stay reusable and easy to test; containers handle the work
• ✅ Co-locate a component with its styles and test in one folder
• ✅ Use clear PascalCase names, one main component per file
• ✅ Split when a component does too much, but don’t over-split into a maze of tiny files

🚀 What’s Next?

Now your components are small, focused, and well-placed. Next we’ll do the same for your custom hooks: where to keep them and how to organize your reusable logic.

React Organizing Hooks