Having a single folder full of components just makes me think you haven’t worked on a large project. Even if you divide it into AMO folders you still end up with hundreds of components.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
having some styling globals 'variables.scss, common.scss, modals.scss, fonts.scss, colors.scss, accordion.scss and so' organised on semantically understandable directory tree.
Then each component has it's own scss where you import (@use) the necessary globals.
We find this was as more suitable for big projects but i'm not sure if it's the best way yet, how do you manage it?
I have actually used this with large teams pretty successfully.
I'm not against a feature folder structure, I think it works fantastic in conjunction with an atomic design structure. There's no one size fits all.
The problem with feature folder layouts is that all components become tightly coupled with their domain context, which works okay for slow changing systems, but not so great for fast paced startups.
Atomic design takes way some of that domain specific context, which has its pros and cons. What I personally do is a combination of what you mentioned, a feature folder layout, along with an atomic design structure for more reusable components.
I found that even with devs coming in and out of a project, it generally works fine and keeps things organized. When we build out storybook for a component, it's easy to keep it in sync with what the design team has, and easy for the design team to audit the current state of the UI.
Perhaps my article came across as a bit dogmatic, but I'm aware that a little controversy usually gets a good conversation going :)
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.
Having a single folder full of components just makes me think you haven’t worked on a large project. Even if you divide it into AMO folders you still end up with hundreds of components.
The better solution is the feature folder layout.
We usually make something like that:
having some styling globals 'variables.scss, common.scss, modals.scss, fonts.scss, colors.scss, accordion.scss and so' organised on semantically understandable directory tree.
Then each component has it's own scss where you import (@use) the necessary globals.
We find this was as more suitable for big projects but i'm not sure if it's the best way yet, how do you manage it?
I have actually used this with large teams pretty successfully.
I'm not against a feature folder structure, I think it works fantastic in conjunction with an atomic design structure. There's no one size fits all.
The problem with feature folder layouts is that all components become tightly coupled with their domain context, which works okay for slow changing systems, but not so great for fast paced startups.
Atomic design takes way some of that domain specific context, which has its pros and cons. What I personally do is a combination of what you mentioned, a feature folder layout, along with an atomic design structure for more reusable components.
I found that even with devs coming in and out of a project, it generally works fine and keeps things organized. When we build out storybook for a component, it's easy to keep it in sync with what the design team has, and easy for the design team to audit the current state of the UI.
Perhaps my article came across as a bit dogmatic, but I'm aware that a little controversy usually gets a good conversation going :)