Are you tired of sifting through a mess of React components and files? You're not alone! As your project grows, keeping your code organized becomes a real challenge. But don't worry – I've got your back. In this guide, I'll walk you through a battle-tested structure that'll make your React projects a breeze to manage.
Why Good Structure Matters
Before we dive in, let's talk about why structure is so crucial. A well-organized codebase isn't just about satisfying your inner neat freak (though that's a nice bonus). It's about:
- Saving time when you need to find and update components
- Making it easier for team members to collaborate
- Scaling your project without losing your mind
Trust me, your future self will thank you for taking the time to set this up right!
The React Project Structure You've Been Dreaming Of
Alright, let's get into the good stuff. Here's a structure that has served me well in countless projects:
📁src
|
|_ 📁components
| |_ 📁Cards
| | |_ 📄MainCards.jsx
| |_ 📁Buttons
| |_ 📄PrimaryButton.jsx
| |_ 📄SecondaryButton.jsx
|_ 📁api
| |_ 📄Auth.js
| |_ 📄Event.js
|_ 📁pages
| |_ 📁HomePage
| | |_ 📄HomePage.jsx
| |_ 📁LoginPage
| |_ 📄LoginPage.jsx
|_ 📁contexts
| |_ 📄AuthContext.js
| |_ 📄EventContext.js
|_ 📁hooks
| |_ 📄useAuth.js
| |_ 📄useEvent.js
|_ 📁utils
| |_ 📄helperFunctions.js
| |_ 📄date.js
|_ 📁assets
| |_ 📁images
| | |_ 📄logo.svg
| | |_ 📄background.jpg
| |_ 📁styles
| |_ 📄global.css
| |_ 📄theme.js
|_ 📄App.jsx
|_ 📄index.js
Looks neat, right? But what does it all mean? Let's break it down.
Components: Your React LEGO Bricks
Think of the components folder as your toybox of LEGO bricks. Each component is a reusable piece that you can snap together to build your app. I like to organize mine like this:
📁components
|_ 📁Cards
| |_ 📄MainCards.jsx
|_ 📁Buttons
|_ 📄PrimaryButton.jsx
|_ 📄SecondaryButton.jsx
Pro tip: Group similar components together. It'll save you hours of hunting later on!
API: Where Your Data Magic Happens
The api folder is all about data fetching. Keep your API calls separate from your UI components – your code will thank you for it. Here's what I usually include:
📁api
|_ 📄Auth.js
|_ 📄Event.js
Pages: The Big Picture
Your pages folder houses the main views of your app. Each page is like a chapter in your app's story. For example:
📁pages
|_ 📁HomePage
| |_ 📄HomePage.jsx
|_ 📁LoginPage
|_ 📄LoginPage.jsx
Contexts: Global State Made Easy
React Context is a game-changer for managing global state. I keep my context files neatly organized:
📁contexts
|_ 📄AuthContext.js
|_ 📄EventContext.js
Hooks: Your Custom React Superpowers
Custom hooks are like your own personal React superpowers. I store mine in the hooks folder:
📁hooks
|_ 📄useAuth.js
|_ 📄useEvent.js
Utils: Your Coding Swiss Army Knife
The utils folder is for all those handy helper functions you find yourself using again and again:
📁utils
|_ 📄helperFunctions.js
|_ 📄date.js
Assets: Pretty Things Go Here
Keep your images, styles, and other static assets organized in the assets folder:
📁assets
|_ 📁images
| |_ 📄logo.svg
| |_ 📄background.jpg
|_ 📁styles
|_ 📄global.css
|_ 📄theme.js
The Root Files: Tying It All Together
Finally, we have our root files that bring everything together:
-
App.jsx: The main component that sets up your app's structure -
index.js: The entry point where your React app comes to life
Wrapping Up: Your Path to React Nirvana
There you have it – a clean, scalable structure for your React projects. Remember, this isn't a one-size-fits-all solution. Feel free to adapt it to your needs. The key is consistency.
By following this structure, you'll spend less time wrangling files and more time building awesome features. Your code will be cleaner, your team will be happier, and your projects will scale like a dream.
So, what are you waiting for? Give this structure a try in your next project. Your future self (and your teammates) will thank you!
Happy coding, and may your React projects always be organized and bug-free!
Top comments (50)
Actually as the project grows larger this structure is not ideal, because the relationship between components and pages will become increasingly difficult to navigate. It's usually better to keep related things together and only make a generic components folder for components that are shared across pages. These can usually be divided into two types: ui components and layout components. In really big projects, ui components (design system) could even live in a separate repo or in a different package in a monorepo.
Agreed. Faced the same issue eventually with a multi-year enterprise project.
We have so many hooks it takes us some time to decipher what each one does and why.
Newer projects all have them grouped by modules with corresponding hooks and components. Makes it much easier for devs to just come in, digest that single module, and make changes.
For more complex requirements, it is also easier to break down changes required at a higher cognitive level when you can see the different logical separations of responsibility between modules.
The rest of the folders (API, pages, context) are project dependent. We also have a top level hook folder for utilities though.
Thank you for sharing your experience. I have faced a similar issue too.
Could you provide an example of how your project structure looks with the grouped modules and corresponding hooks and components?
Also, how do you determine whether a hook or component should be grouped into a specific module or placed at the top level? Do you have any guiding principles for this, or do you start by creating them in specific modules and move them to the top level when you find they are used in multiple cases?
Group hooks and components by functionality or feature; promote them to the top level if they are used across multiple modules. Start specific and refactor as needed for reusability.
Yes. Better to organize hooks, contexts and components per page/domain. Usually I also create a context for each page, so logic is separated from ui components. Also helps with testing.
Cool!
Yeah , it can not be used in large Size projects!
You can use component naming convention to separate generic (design system) components from related components like so:
MyCoolProjectInput
MyCoolProjectlabel
MyCoolProjectChatInput
MyCoolProjectChatLabel
Yes.
Agree. And don't mind these posts. They are for newbie only. More clickbait than actual experience. It's fun though, watching peole fall for this time and time again
Good idea.
Previously i'm separate react folder by feature like this
In root or src folder i create
App.jsx
index.jsx
Components for all customize component
Pages/ for all pages, in pages folder there all feature layout and each feature available folder like hook, hook folder want to take or Processor query params, route,etc for used to view folder
view/ many component in all feature like api,view core component,hook,context,etc
Asset/
Tq!
👍My
apifolder isservice😄Thank you for these guide. You really helped me. I'm new to front-end and this guide will help me better understand how to structure projects.
Welcome!
This approach might work for a small project but simply would not scale.
Any production app would easily have 100s of hooks, until files and not even mentioning actual components. Navigating through something like that would simply be a nightmare.
Yes!
@tacotoemeck please what would be the best practice for big project ?
Could you share your suggestion in a visual manner for a scalable structure?
This whole structure thing, I don't believe there is "one partner fit all" for every project. Of course your suggestion does provide some basics. So it is appreciated.
Thanks for sharing.
Yeah It can not be fit for all kind of projects!
Good Article Thank you bro
Have A Good Day
Thanks!
It's better to move the context in the same file of the component that valorize it and to move the hooks along with the utils. Hooks are already identified by the use keyword.
You only need 5 folders: components, pages/routes, assets, utils/modules, api
The point of components and modules is to organize the code by domain rather then technical responsibility
Yup!
As the project grows bigger this is really going cos a problem I think. For instance having all the styles in one folder to me is not ideal. What do you think of this approach 📁Cards => then inside the Cards Folder you have Cards.jsx and Cards.CSS.
This way I think you can be well organized and know what Style belongs to what component.
For larger projects, for sure it will change.
Hmnnn! Looks better to me. Looks like an object approach to structure.
This is better than those only identifying problems without suggestions.
Thanks!
Good structure, this is more or less how I'm also doing it :)
As other people have remarked, for a REALLY big app you might want to embrace the "module" idea, so you have (for example) a "payroll" folder (module), and below that components/pages/hooks, an "hours" folder with components/pages/hooks, etc ...
But, for a not-so-huge app, I think this is just fine.
Thank you Vishal for writing this article, this has really helped me to clear a lot of issues behind creating a good folder structure in React. I am very happy with the ideas a lot of experienced devs have given in this article, but for developers like us that don't have real world experience yet, I would advice that starting from somewhere matters, you can't start building production style structure when you can't create a basic working structure, everything will change as you keep doing more work and improving the way you write code, but this article is a good foundation to start from somewhere
Nice but how about the test folder and so how will you structure the files that will be tested ?, feel free to update it thanks because in reality all prooduction applications grows so how do we handle that complexity since we must write a test before deployment ?
Definitely worth checking this post for any beginner who wonders "where should I create a new API folder?". These seem Basic but yet something that most of us miss while learning the technology at beginner level or a self taught programmer (at least I've missed that)
Would be much appreciated if you can also share "How to extend your project when you add a new packages and still have the project structure organized"
I always come across this question in my early days, when adding a package like trpc, Jotai, or adding types etc.
Once again Thanks for sharing 👏
This grouping looks good at first but it's actually missing SOLID's colocation principle. You should keep related functionality as close as possible from each other while retaining hierarchy.
The ideal looks like a repetition of this at any nested level. What does that mean? If you have a checkout component some levels deep on a page, all related API calls, non-reused ui components, layouts and types must sit closely to your checkout, not close to your app root.
Great view, I usually follow the atomic design
When I began use it, I found a structure more readable and navigable
I created a simplify structure, like this:
I removed the template section, because it's too verbose for me while developing.
What do you think about this?
Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more