Organizing files and directories within a React project is necessary for maintainability, scalability, and ease of navigation. This article explores the general architecture and folder structures across different scales of React projects, providing clear demonstrations for each level.
1️⃣ Level 1: Grouping by “File Types”
This structure is characterized by its simplicity – grouping files by their type:
├── assets/
├── api/
├── configs/
├── components/
│ ├── SignUpForm.tsx
│ ├── Employees.tsx
│ ├── PaymentForm.tsx
│ └── Button.tsx
├── hooks/
│ ├── usePayment.ts
│ ├── useUpdateEmployee.ts
│ ├── useEmployees.ts
│ └── useAuth.tsx
├── lib/
├── services/
├── states/
└── utils/
Project Size: Small to Medium
Advantages: Simple & straightforward
Disadvantages:
Will inflate quickly and become hard to maintain
No separation of business concerns
Let’s say you have a lot of code revolving around payment. One day the whole business changes or is no longer needed, how easy is it to replace or remove it? With this folder structure, you’ll have to go through every folder and the files inside it to make the necessary changes. And if the project keeps growing larger, it’ll soon grow into a maintenance hell that will only get worse over time.
2️⃣ Level 2: Grouping by “File Types” and Features
As projects grow, the “Level 2” structure introduces grouping by feature within each type:
├── assets/
├── api/
├── configs/
├── components/
│ ├── auth/
│ │ └── SignUpForm.tsx
│ ├── payment/
│ │ └── PaymentForm.tsx
│ ├── common/
│ │ └── Button.tsx
│ └── employees/
│ ├── EmployeeList.tsx
│ └── EmployeeSummary.tsx
├── hooks/
│ ├── auth/
│ │ └── useAuth.ts
│ ├── payment/
│ │ └── usePayment.ts
│ └── employees/
│ ├── useEmployees.ts
│ └── useUpdateEmployee.ts
├── lib/
├── services/
├── states/
└── utils/
Project Size: Medium to Large
Advantages:
Simple & straightforward
Stuff are grouped by features
Disadvantages:
Logic related to a feature is still spread across multiple folder types.
Now let’s come back to the problem statement where the payment module needs to be modified or removed. With this structure, it’s a lot easier to do that now.
The “Level 2” folder structure is the one that I’d recommend if you don’t know what to choose.
3️⃣ Level 3: Grouping by Features/Modules
For larger projects, the “Level 3” structure offers a highly modular approach, defining clear boundaries for different aspects of the application within each module:
├── assets/
├── modules/
| ├── core/
│ │ ├── components/
│ │ ├── design-system/
│ │ │ └── Button.tsx
│ │ ├── hooks/
│ │ ├── lib/
│ │ └── utils/
│ ├── payment/
│ │ ├── components/
│ │ │ └── PaymentForm.tsx
│ │ ├── hooks/
│ │ │ └── usePayment.ts
│ │ ├── lib/
│ │ ├── services/
│ │ ├── states/
│ │ └── utils/
│ ├── auth/
│ │ ├── components/
│ │ │ └── SignUpForm.tsx
│ │ ├── hooks/
│ │ │ └── useAuth.ts
│ │ ├── lib/
│ │ ├── services/
│ │ ├── states/
│ │ └── utils/
│ └── employees/
│ ├── components/
│ │ ├── EmployeeList.tsx
│ │ └── EmployeeSummary.tsx
│ ├── hooks/
│ │ ├── useEmployees.ts
│ │ └── useUpdateEmployee.ts
│ ├── services/
│ ├── states/
│ └── utils/
└── …
Project Size: Large and Complex
Advantages:
Stuff are clearly grouped by features/modules
Features/Modules are clear representations of objects in the real world
Disadvantages:
You’ll have to be well-aware of the business logic to make the right grouping decisions
With this, if you are to remove or modify the payment logic, you’ll know right away where to start.
**Muhammad Haris Ahsan**
I’m a Full stack enthusiast who is specialized in ⚛️. I love sharing my knowledge and experience within my area of expertise.
👋 Before you go
Please leave your appreciation by commenting on this post!
Happy coding ❤️
