I work with pedagogies, teach, write curricula, coach, manage, mentor, consult, speak publicly, polemicize, and sometimes work as a full-stack web developer, architect, ontologist, and more.
I don't find this "clean" at all. I find it remarkably annoying. And it's everywhere.
When I work on an app, I don't generally work on all the components, or all the hooks, or all the routes. I work on FEATURES.
The best way to organize an app, especially a front end app, is by FEATURE. If I have, for example, a profile page, then I have a Profile folder and I have everything to do with that feature in that folder: routes, api calls, tests, storybook, CSS, components that are unique to that FEATURE, etc.
If I have shared components, then I put them in a shared folder no higher than the node at which the branches that use that component meet. Ditto for utility functions.
This way, I have everything right where I need it when I'm working on a FEATURE. Isn't that what most devs work on? My application's folder hierarchy follows the nesting of the components in the app. If a component is used only by another component, then it is in its parent component's folder: right where you'd expect it to be.
And if the feature needs to be moved, I just move the folder and change the references (which VSCode does for me automatically). If I delete it, I delete everything and I only have to find the references to it (e.g., a route in a router). I don't have to search through dozens of folders and files to find all the pieces.
If only more devs would try this, I think they'd like it. Think about how the code ought to be organized (loosely-coupled features) rather than some arbitrary taxonomy of file types.
I suspect that the system recommended in this article, which is, frankly, ubiquitous, is the result of too many back end devs trying to do front end architecture and just using what they know. The client side deserves better.
Yeah, agree on this one. I believe it is sometimes referred to as "vertical slice architecture".
Also I tend to violate DRY quite often, meaning that some code is duplicated across features. For example to avoid a feature being dependent on shared folder(s) or packages when it is only using one or a few shared functions
So your point of view was so much clean to understand, thanks to collaborate am i FE dev in a transition do Mid > Senior and your answer helped me a lot to get another ideas.
I work with pedagogies, teach, write curricula, coach, manage, mentor, consult, speak publicly, polemicize, and sometimes work as a full-stack web developer, architect, ontologist, and more.
I am not criticizing how the author works. That's entirely up to the author (or the team).
I am criticizing what the author recommends to others. Anyone who gets up on a soapbox (myself included) is fair game for criticism having essentially put it out there and asked for it.
I agree 10000% with you.
The way you said it is a much more practical way of organizing projects on the frontend.
The clean arc works great on the backend, but it stops there.
While it's good for a frontend to be inspired by backend architectures, it needs to be clear about what works and what doesn't and needs adaptation.
I am this "back end guy" you are talking about, and yes we want to bring back end best practices to the front end. Since the practices we see in the front end are not convincing to us, sorry...
The feature based approach, yes I have also seen it many times, has the general flows of:
countless self repetition, and no chance to handle on problem in a central way
It might work for a small team, but once you have 5 people working on the code base, there is no way to easily find any logic that is already written by others. Instead of knowing that my service for my business object will exist and I am centralizing all my logic there, its written again and again, in many single random files with single exported functions
if a enter a mature code base as a new team member, I will have to go through all the code searching for all kinds of logic to probably find something that fits for my new requirement, instead of knowing of 3-5 centralized services that I can easily locate by the domain object name
since a team never communicates a central architecture, as presented here, patterns of the system are build randomly on the feature base, same logic is distributed all over the place, I am sorry but how is this a good approach?
I never used directly the CLEAN architecture, but I always talk about a "domain oriented" approach it ends up being something more simpler like the architecture presented here. The core Idea is the same, the whole app is split into domains, business and tech and this is basic separation of concerns...
I don't find this "clean" at all. I find it remarkably annoying. And it's everywhere.
When I work on an app, I don't generally work on all the components, or all the hooks, or all the routes. I work on FEATURES.
The best way to organize an app, especially a front end app, is by FEATURE. If I have, for example, a profile page, then I have a
Profilefolder and I have everything to do with that feature in that folder: routes, api calls, tests, storybook, CSS, components that are unique to that FEATURE, etc.If I have shared components, then I put them in a
sharedfolder no higher than the node at which the branches that use that component meet. Ditto for utility functions.This way, I have everything right where I need it when I'm working on a FEATURE. Isn't that what most devs work on? My application's folder hierarchy follows the nesting of the components in the app. If a component is used only by another component, then it is in its parent component's folder: right where you'd expect it to be.
And if the feature needs to be moved, I just move the folder and change the references (which VSCode does for me automatically). If I delete it, I delete everything and I only have to find the references to it (e.g., a route in a router). I don't have to search through dozens of folders and files to find all the pieces.
I explained this as part of a discussion on micro-apps here: Micro-app file/folder hierarchy.
If only more devs would try this, I think they'd like it. Think about how the code ought to be organized (loosely-coupled features) rather than some arbitrary taxonomy of file types.
I suspect that the system recommended in this article, which is, frankly, ubiquitous, is the result of too many back end devs trying to do front end architecture and just using what they know. The client side deserves better.
Yeah, agree on this one. I believe it is sometimes referred to as "vertical slice architecture".
Also I tend to violate DRY quite often, meaning that some code is duplicated across features. For example to avoid a feature being dependent on shared folder(s) or packages when it is only using one or a few shared functions
Thank you very much it's just what I needed.
So your point of view was so much clean to understand, thanks to collaborate am i FE dev in a transition do Mid > Senior and your answer helped me a lot to get another ideas.
Not forgetting how much easier it get when you start to use feature flags.
But I don't want to criticise the way others work, as long as it delivers a good, maintainable product.
Just saw this.
I am not criticizing how the author works. That's entirely up to the author (or the team).
I am criticizing what the author recommends to others. Anyone who gets up on a soapbox (myself included) is fair game for criticism having essentially put it out there and asked for it.
I agree 10000% with you.
The way you said it is a much more practical way of organizing projects on the frontend.
The clean arc works great on the backend, but it stops there.
While it's good for a frontend to be inspired by backend architectures, it needs to be clear about what works and what doesn't and needs adaptation.
Hi Charles, sorry I disagree.
I am this "back end guy" you are talking about, and yes we want to bring back end best practices to the front end. Since the practices we see in the front end are not convincing to us, sorry...
The feature based approach, yes I have also seen it many times, has the general flows of:
countless self repetition, and no chance to handle on problem in a central way
It might work for a small team, but once you have 5 people working on the code base, there is no way to easily find any logic that is already written by others. Instead of knowing that my service for my business object will exist and I am centralizing all my logic there, its written again and again, in many single random files with single exported functions
if a enter a mature code base as a new team member, I will have to go through all the code searching for all kinds of logic to probably find something that fits for my new requirement, instead of knowing of 3-5 centralized services that I can easily locate by the domain object name
since a team never communicates a central architecture, as presented here, patterns of the system are build randomly on the feature base, same logic is distributed all over the place, I am sorry but how is this a good approach?
I never used directly the CLEAN architecture, but I always talk about a "domain oriented" approach it ends up being something more simpler like the architecture presented here. The core Idea is the same, the whole app is split into domains, business and tech and this is basic separation of concerns...
Can I explain and show better architecture in react.js?