I disagree, from the perspective of coding frontend projects for almost 2 decades, atomic-design principles are fantastic way to organize code front-end code.
Many projects I see are a mess of 100+ components all in one folder (src/components) and a new developer cannot possibly know which is a small basic one and which is a whole page (full of other components).
just like you make order in your life in every aspect, like not mixing your underwear with your socks, you don't want throw all the components into one folder. it's a mess.
So, obviously there is a need for splitting things to groups.
Regarding your example of button, you don't need to think of atomic-design components as a visual thing but more of a collection of concepts. A button can have a thousand appearances, don't matter. Still all buttons in the app should use the button component, to have a single-entity in charge of the buttons (and of course you may pass different optional variants for styling)
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
Atomic design is ok as reference but not as a copy paste of methodology because it came to solve a different need. First of all you need to define what an atom is, and atoms are always the smaller building blocks.
What you talk about is components architecture in which you can group your items into src/components/anyTaxonomy, the difference between both ways to structure things is one little (maybe) but important.
On a component you define a button that can take N different flavours depending on X.
An atom starts being each piece of those flavour that makes the button different. Then it can form molecules being them the result of each flavour.
That's why you use a component called button that can take some arg to define how it will look like, because it's called differently on each context, whereas if you use a strict atomic methodology (in which I must insist, is meant for design, not for coding even CSS) you'll end up with tones of little pieces of code that eventually form "molecules" and lately components.
Atomic design (note the design word) works well for designers because they can import visuals inside other visuals and if a visual is modified, it changes on everywhere. This is just what we want to reach on code, of course, but the way to achieve it easily is using components, not atoms, using variables for this styling as opposite to static references to a given object like in design frameworks or tools suck Sketch.
In CSS you can define "atoms" and "molecules" and make it working together pretty good mimicking this methodology as long as you use some pre-processor such SCSS and maintain your code well on the long time (you know, if it's a change, it's a change, not an addition or an override), but at the end you'll loose less time if you create components as well in CSS, usually known as BEM in which you define the blocks, the elements and the modifiers which if compared to a component architecture is pretty similar. A component has a scope, it's root element, child elements (that hopefully will be other components as well) and it's args (modifiers).
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 disagree, from the perspective of coding frontend projects for almost 2 decades, atomic-design principles are fantastic way to organize code front-end code.
Many projects I see are a mess of 100+ components all in one folder (
src/components) and a new developer cannot possibly know which is a small basic one and which is a whole page (full of other components).just like you make order in your life in every aspect, like not mixing your underwear with your socks, you don't want throw all the components into one folder. it's a mess.
So, obviously there is a need for splitting things to groups.
Regarding your example of
button, you don't need to think of atomic-design components as a visual thing but more of a collection of concepts. A button can have a thousand appearances, don't matter. Still all buttons in the app should use thebuttoncomponent, to have a single-entity in charge of the buttons (and of course you may pass different optional variants for styling)Atomic design is ok as reference but not as a copy paste of methodology because it came to solve a different need. First of all you need to define what an atom is, and atoms are always the smaller building blocks.
What you talk about is components architecture in which you can group your items into src/components/anyTaxonomy, the difference between both ways to structure things is one little (maybe) but important.
That's why you use a component called button that can take some arg to define how it will look like, because it's called differently on each context, whereas if you use a strict atomic methodology (in which I must insist, is meant for design, not for coding even CSS) you'll end up with tones of little pieces of code that eventually form "molecules" and lately components.
Atomic design (note the design word) works well for designers because they can import visuals inside other visuals and if a visual is modified, it changes on everywhere. This is just what we want to reach on code, of course, but the way to achieve it easily is using components, not atoms, using variables for this styling as opposite to static references to a given object like in design frameworks or tools suck Sketch.
In CSS you can define "atoms" and "molecules" and make it working together pretty good mimicking this methodology as long as you use some pre-processor such SCSS and maintain your code well on the long time (you know, if it's a change, it's a change, not an addition or an override), but at the end you'll loose less time if you create components as well in CSS, usually known as BEM in which you define the blocks, the elements and the modifiers which if compared to a component architecture is pretty similar. A component has a scope, it's root element, child elements (that hopefully will be other components as well) and it's args (modifiers).