Just showing off my current preference for a React project folder structure. I think this gives a good view and segregation of files for my react based projects.
Let's go through each folder inside the src folder.
1. api-config
api-config consist of file containing the api endpoints. This folder doesn't have any logic. This helps having a single place for all api url end points and not to be scattered around in components, mostly inside useEffects.
2. assets
assets folder mostly consist of images(.png,.svg..) and any other static files that might be needed.
3. common
common folder is divided into more react specific folders.
components folder consists of individual components, which are atomic in nature and doesn't compose any other components.
hooks as the name suggest consists of custom hooks, that you might develop for your project
4. constants
constants as the name suggest consist of constants used across project
5. modules
modules folder contains react components which are composed of smaller components defined under common/components. For e.g. a <Header /> component which may look like
<>
<Title />
<Image />
<Menu />
</>
6. pages
pages are one to one map of the router routes. This is similar to the concept that NextJS or GatsbyJs takes.
This is the bigger react component which presents a whole page. It might contains additional routing, so more nested pages. An example of this page will be dashboard page which might look like (in it's simples form)
<>
<PageHeader />
<PageTopMenu />
<PageLeftNavigation />
<VisitorBlockChart />
<VistorLineChart />
<SomeOtherAwesomeComponent />
<PageFooter>
</>
7. store or Global context
store folder contains global store or global context that are getting used across product.
On side note, if you have not used Zustand as react-redux replacement, give it a try. Very simple and easy to use state management system and you don't have to wrap your component inside a Provider.
Zustand
8. test
Test folder. And please don't give it just a lip service. It's fun to write and really helps you out during refactoring(more than TypeScript.. :P)
React-testing-library
9. utils
Everything else to dump into(..not really, please don't do this).
Store common utility functions inside this folder.
10.routes
A folder to contains all root level routes.
End Note
This folder structure has evolved in last one year and really helping me out in couple of my current big project.It doesn't mean that It will not change again, but at least for my next project, I will continue to use this structure.
Let me know what your preferences are these days?
Till Next Time
Kumar Nitesh
@knitesh
Twitter: @imknitesh
Top comments (19)
Great structure. I use almost the same except 2 folders:
And also a "types" folder whether I use TS or not(usually I do)
But I think I'll upgrade my structure and add common folder. Thanks for the idea.
I still need to use Typescript, have been hearing lots of good stuff about it.
To be honest it has some bugs. On one of the conferences it was told that due to the bug in typescript a person died. The main idea was that it was a medical app and it was for doctors. The app did not render allergies block, cause it was based on typescript Map and there was a bug with copying that map. And the doctor did not see the allergies.
But anyway, imho it is more the case for not good test coverage.
Hey Kumar, thanks for sharing it! I have a question, may I know does this file structure applicable to Next.js React Full Stack App too? I want to include front-end & back-end but I am not really sure how to structure it. I have Googled a lot.
Hi Eugene,
For a full stack Next project, I still prefer to create
client&serverfolder right undersrc. The server folder structure differs then the client folder, in the sense all server logic, like DB interactions, authentication, goes under server folder, but all UI related logic and routes goes under client folder.I try to keep it separate just like any react project, even when it is using NExt.js where everything is on the server side.
Also, look at
https://github.com/oh-my-c0de/oh-my-fullstack, it has skeleton project for your need. Use it as starting point, and then come up with your own folder structure.Thank you.
That's a great structure to inspire people. Took me sometime till I figured out my own way to organize stuff, but is pretty close to yours. Main difference is hooks and components are at top level.
And yes, TESTing is super important, we have to keep it in mind. 😉
This post inspired me to look at Next.js and Nuxt.js docs, and behold, both contain an option to put your /pages and whatnot folders under /src. The fact that the root is so populated erks me so much and I can't do a search to a single folder. This makes the folder structure so much cleaner.
I use a very similar structure in many apps I write, but I haven't used a folder structure that splits them into three levels like this. That's a nice idea!
That's not an anecdote)
As I remember this was a story by Ilya Klimov, his channel is JavaScript Ninja and he told this on one of the conferences and the project was private. So that's why you can't find it on internet)
I wrote a very simple tool that can be added to a precommit hook and/or pipeline to help enforce directory structure. It has no usage and isn't published to npm. github.com/mattferrin/folder-struc...
My first opinion is that api-config, modules, pages, and stores spread features across multiple folders unnecessarily and might make naming consistency more difficult. My second opinion is that utils and common are basically the same feature in two places.
I personally group by feature at the top level and then by functions, objects, types, components, and hooks within each feature.
Thanks for sharing. I remember someone once told me that when looking at your arc folder you should know what this website is meant for, and this is how I organize my folders veer since. How do you find this aproach?
This is a tough questions.
Normally, the project name and description in package.json should tell you what your project/website is for. You can have your folder name with prefix of the the work that you doing, for e.g., if you developing a e-commerce website, you can append ecom-. But it will be tough. For me this common structure has worked and it's easy for any developer from other team to join and immediately know where the code will go.
+1 for zustand
Awesome alternative for state management
I would add a
typesfolder when using typescriptThis is so simple yet so amazing. I always struggle to organize the files. Thanks
Could you update the spelling for
assest=>assets. Basically I'm following this stracture. Thanks