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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.