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...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
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 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!
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?
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.
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!
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!
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.
i would suggest "api" dir will be name as "service", so that you can actually put any kind of external services in any protocols like REST or GraphQL, RPC...
You can change it according to you.
yes it should be in service folder....
same with tha utils
utils/dataUtils every one utils must de a directory
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?
where to put specific components for example I have a component slider and it is only used on the home screen?
You can put inside
<3
Great! I use something similar too but include the CSS files of every react component in the same folder as the components.
Yeah!
I prefer nowadays with big projects work building scalable react applications with feature-based architecture
Thanks 👍🏽
👎 structure, I think use fds for frontend structure
Ok!
Great job!
React folder structure discussion is incomplete without considering Redux and incorporating folder structure for Redux components as well.