Structuring React applications into files and folders is an opinionated topic, because there is no right or wrong way to do it. I decided to share ...
For further actions, you may consider blocking this person and/or reporting abuse
Organise by feature, not by nature. Putting all your components in one directory and your hooks in another doesn't make sense. One feature will be split across multiple top level directories. I don't know why people organise this way in react when you don't see it in almost any other framework (for good reason).
I agree with @insidewhy . I've seen a lot of projects organised by nature, not by feature which makes future maintenance really hard not only from the perspective of having a massive folder with components but also moving them around between different projects.
Hey morning dude, do you have a project example ? have nice day ;)
I do not have a project example for your unfortunately because all of them would still be under NDA right now. Nevertheless, to give you a little bit of an idea consider the explanation below. The main distinction here is the difference between organising your projects vertically (per feature), horizontally (per function eg. components, services etc.) or finding some solution in the middle (reusable elements per function, rest per feature).
Organising your projects horizontally is completely fine if your app is not overly big. Unfortunately as a project grows what happens very often is that the components folder (let's use this one as an example) will become a massive flat-structured dump for all the components that you have in the app. Other folders like services, data, hooks thingies or whatever you use as layers in your app will follow the forlorn fate of the components folder. What you end up is a basically a pile of latkes. Not only React front-end apps suffer from this issue - I have seem this problem appear in NodeJS and iOS apps as well. This is not great for the following reasons:
Imagine you're a new developer joining the team. A junior one to use an edge case. You will end up having to navigate through all of the latke layers to solve one simple task that has been assigned to you. The learning curve is much steeper and probability that you will make mistakes in the beginning is much higher.
Imagine you've got a request to remove a feature. Instead of getting rid of one folder, you need to slice through each single of the latkes that you have there. In the best case you'll be removing some files from a couple folders. In the worst one, removing tons of related dependencies. The worst case is an equivalent of someone putting a lot of long curly hair into your latkes mixture.
Imagine an entire feature that's in your app (for example - authentication, some calculator that you might have there or any other reusable feature) suddenly needs to be used in another project. This happens surprisingly often if you work within an organisation that has multiple teams using similar tech. If you're stuck with the folder structure of components / hooks / services. etc, you will have to move each one of them one by one in the best case.
The list goes on, those are just some examples.
To reiterate on the previous point - do what's best for you and your project and the team that you're working with. There is not single grand truth that will tell you how each project in the whole wide universe should be organised. If you expect the app to grow or have components of views / business logic that are reusable sticking to a horizontal structure will make you more miserable than you need to be. We don't want that.
It's not all black and white though and there are some solutions that could place itself in the middle. One could use the following heuristic - is a the component used more than once? If yes, put it in the components folder, if not stick with a folder structure that puts a clear division between different features of the app.
Maybe it's better to organize by both. How about a generic hook like
useModalthat can be used by ANY modal in your project. Isn't organizing it by nature a better model than anything else?Add it to an open source library or a
utilsfolder in the root or evenmodalsorutils/modals. Nothooksfolder. At my current job we use a monorepo and have subpackages for things like this so we can share generic functionality with many projects.Agree, you could take a look at awesome architecture for frontend projects: feature-sliced.design/en
Awesome. Nice structure. What's your editor and themes?
Hey, I used ray.so/ for the images.
Thanks for this. I appreciate.
Finally one which is easy to follow :)
Thanks!
This structure is good enough, but just one issue exists here and that is when we want search index.tsx files and then we get very much results of them and it's painful for me as I have experience about this for finding the specific index file.
I propose fractal structure for react apps and in near feature I will discuss about it in new article.
Good luck
I don't agree with the idea of keeping partial components inside the main component. Even if the partial component is small, I would rather to have a standard, to make the project structure more legible :D
But I loved these ideas! Thx
Excellent, Thanks!
You’re welcome!
This makes perfect sense, thanks for sharing :)
You’re welcome!
What about css files? Where need to place it?
CSS/ SASS should be split per component basis and placed in the corresponding component folder with same name as of component (i.e.
Header.tsxandHeader.cssshould be placed insrc/components/Header) . Global styles or themes should be placed insrc/stylesfolder.why you don't share a git repo?
Nice and clean, I try to keep the root folder of a project clean and empty so my brain can start there and then dive into the area of interest as I go.
Although this might fit for similar usecases but
react-file-structure.surge.sh/
This is from dan abramov himself. There is no one size fit all solution.
Clean Architecture for the win.
Nice one but i think project should be organised by feature (responsibility principle) and i also belive in the KISS principle.