When I first started building React applications years ago, I didn’t think much about folder structure. I would just throw components, hooks, and assets into a single folder and move on.
But as projects grew, I quickly realized that an unorganized structure made maintenance painful, especially when multiple developers were working on the same codebase.
In this article, I’ll share React component file structure best practices that I’ve learned over the years. These are the same principles I use today when building large-scale web applications for clients.
Why Folder Structure Matters in React
A well-thought-out folder structure helps you:
- Scale easily as your app grows.
- Find files quickly when debugging or refactoring.
- Collaborate efficiently with other developers.
- Avoid naming conflicts and redundant code.
Think of it like organizing your kitchen. The more structured it is, the faster you can find what you need, and the easier it is for others to help.
Method 1 – The Simple “File-Type” Structure
This is a great starting point for small to medium projects. You group files by their type, components, pages, hooks, and so on.
Here’s what the structure looks like:
src/
│
├── components/
│ ├── Header.js
│ ├── Footer.js
│ └── Button.js
│
├── pages/
│ ├── Home.js
│ └── About.js
│
├── hooks/
│ └── useFetch.js
│
├── assets/
│ ├── images/
│ └── styles/
│
├── App.js
└── index.jsThis structure works well when your app is small, maybe a simple dashboard or a prototype.
But as your app grows, you’ll notice that related files (like a component’s CSS, test, and logic) are scattered. That’s when it’s time to move to a feature-based structure.
Method 2 – Feature-Based Folder Structure (Recommended)
Here, everything related to a specific feature (components, styles, tests, and hooks) lives in one folder. It’s modular, scalable, and easy to maintain.
Here’s an example:
src/
│
├── features/
│ ├── users/
│ │ ├── components/
│ │ │ ├── UserCard.jsx
│ │ │ └── UserList.jsx
│ │ ├── hooks/
│ │ │ └── useUsers.js
│ │ ├── services/
│ │ │ └── userService.js
│ │ ├── styles/
│ │ │ └── user.css
│ │ ├── index.js
│ │ └── tests/
│ │ └── UserCard.test.js
│ │
│ ├── products/
│ │ ├── components/
│ │ │ ├── ProductCard.jsx
│ │ │ └── ProductList.jsx
│ │ ├── hooks/
│ │ │ └── useProducts.js
│ │ ├── services/
│ │ │ └── productService.js
│ │ ├── styles/
│ │ │ └── product.css
│ │ └── index.js
│
├── shared/
│ ├── components/
│ │ ├── Button.jsx
│ │ └── Modal.jsx
│ └── utils/
│ └── formatDate.js
│
├── App.jsx
└── index.jsEach feature is self-contained. You can easily move, rename, or delete a feature without breaking others.
Example: A Simple User Feature
Let’s create a small User feature using this structure.
File: src/features/users/components/UserCard.jsx
import React from "react";
import "./user.css";
const UserCard = ({ name, email }) => {
return (
<div className="user-card">
<h3>{name}</h3>
<p>{email}</p>
</div>
);
};
export default UserCard;File: src/features/users/hooks/useUsers.js
import { useEffect, useState } from "react";
export const useUsers = () => {
const [users, setUsers] = useState([]);
useEffect(() => {
fetch("https://jsonplaceholder.typicode.com/users")
.then((res) => res.json())
.then((data) => setUsers(data));
}, []);
return users;
};File: src/features/users/UserList.jsx
import React from "react";
import UserCard from "./components/UserCard";
import { useUsers } from "./hooks/useUsers";
const UserList = () => {
const users = useUsers();
return (
<div>
<h2>Registered Users</h2>
{users.map((user) => (
<UserCard key={user.id} name={user.name} email={user.email} />
))}
</div>
);
};
export default UserList;File: src/features/users/styles/user.css
.user-card {
border: 1px solid #ddd;
padding: 10px;
margin: 8px 0;
border-radius: 4px;
background-color: #f9f9f9;
}This setup keeps everything related to “users” in one place, making it simple to maintain and test.
Method 3 – Domain-Driven Structure for Large Applications
When working on enterprise-level apps (for example, a healthcare dashboard or a retail management system), I prefer a domain-driven approach.
Here, the structure mirrors the business logic, not just UI features.
For instance:
src/
│
├── domains/
│ ├── authentication/
│ │ ├── components/
│ │ ├── services/
│ │ └── hooks/
│ ├── billing/
│ ├── analytics/
│ └── users/
│
├── shared/
│ ├── components/
│ ├── hooks/
│ └── utils/
│
├── App.jsx
└── index.jsThis works beautifully when multiple teams work on different domains. Each domain can evolve independently, a must for large organizations.
Method 4 – Atomic Design Structure (For Design Systems)
If you’re building a design system or a UI library, the Atomic Design structure is a great choice.
It breaks components into five categories: atoms, molecules, organisms, templates, and pages.
src/
│
├── components/
│ ├── atoms/
│ │ ├── Button.jsx
│ │ └── Input.jsx
│ ├── molecules/
│ │ ├── FormGroup.jsx
│ │ └── Card.jsx
│ ├── organisms/
│ │ ├── Header.jsx
│ │ └── Footer.jsx
│ ├── templates/
│ │ └── MainLayout.jsx
│ └── pages/
│ ├── HomePage.jsx
│ └── AboutPage.jsxThis structure is ideal when UI consistency is a top priority, for example, in large-scale SaaS products or internal component libraries.
Additional Tips for Structuring React Projects
Here are some best practices I always follow:
- Keep file names consistent. Use PascalCase for components, camelCase for hooks, and
kebab-casefor folders. - Use index.js files to simplify imports.
- Avoid deep nesting. If you find yourself going beyond 3 levels, reconsider your structure.
- Group tests with the feature. Keep test files close to their components.
- Separate UI from logic. Use custom hooks for data fetching and state management.
When you follow a clear and consistent folder structure, your React projects become easier to scale, debug, and collaborate on.
Over the years, I’ve seen that even small improvements in organization can save hours of development time down the road.
You may like to read:
- Build a React Text Editor Component
- Build a Reusable React Component with Generic Type
- When Does a React Component Re-render?
- Create a Dynamic Component in React JS

I am Bijay Kumar, a Microsoft MVP in SharePoint. Apart from SharePoint, I started working on Python, Machine learning, and artificial intelligence for the last 5 years. During this time I got expertise in various Python libraries also like Tkinter, Pandas, NumPy, Turtle, Django, Matplotlib, Tensorflow, Scipy, Scikit-Learn, etc… for various clients in the United States, Canada, the United Kingdom, Australia, New Zealand, etc. Check out my profile.