- \n
- Lack of Styleguide of components;<\/span><\/li>\n
- Lack of precision in estimating development time;<\/span><\/li>\n
- Great amount of setup time for developers;<\/span><\/li>\n
- Inconsistency between components and view;<\/span><\/li>\n
- Repeated code;<\/span><\/li>\n
- Side effects;<\/span><\/li>\n
- Very specific components to each pages;<\/span><\/li>\n<\/ul>\n
We\u2019ve started to build the CSS architecture using the ITCSS<\/a> methodology that organizes the style files on stacks from generics styles to the specifics ones, which helps you to scale large projects easily. But along with ITCSS, we were using CSS Modules to scope the components, so we noticed that component stack was getting huge and even the generic styles were being componentized and reused within other one.<\/span><\/p>\n
That was the moment in which we paused to rethink our architecture and how we could set the components in a more distributed and organized way. Then we found a methodology called <\/span>Atomic Design<\/b><\/a> that creates multiples stacks of components, with different hierarchies of complexity and dependence.<\/span><\/p>\n
![\"\"](\"https:\/\/ckl-website-static.s3.amazonaws.com\/wp-content\/uploads\/2017\/12\/Atomic-Design.png\")
<\/p>\nWhat is Atomic Design?<\/span><\/h2>\n
Popularly known within the design world, Atomic Design helps to build consistent, solid and reusable design systems. Plus, in the world of React, Vue and frameworks that stimulate the componentization, Atomic Design is used unconsciously; but when used in the right way, it becomes a powerful ally for developers.<\/span><\/p>\n
The name Atomic Design comes from the idea of separating the components in atoms, molecules, organisms, templates and pages, like in the image above. But what are the responsibilities of each separated part?<\/span><\/p>\n
Atoms<\/h3>\n
![\"\"](\"https:\/\/ckl-website-static.s3.amazonaws.com\/wp-content\/uploads\/2017\/12\/Atoms.png\")
<\/p>\nAtoms are the smallest possible components, such as buttons, titles, inputs or event color pallets, animations, and fonts. They can be applied on any context, globally or within other components and templates, besides having many states, such as this example of button: disabled, hover, different sizes, etc.<\/span><\/p>\n
Molecules<\/h3>\n
![\"\"](\"https:\/\/ckl-website-static.s3.amazonaws.com\/wp-content\/uploads\/2017\/12\/Molecules.png\")
<\/p>\nThey are the composition of one or more components of atoms. Here we begin to compose complex components and reuse some of those components. Molecules can have their own properties and create functionalities by using atoms, which don’t have any function or action by themselves.<\/span><\/p>\n
Organisms<\/h3>\n
![\"\"](\"https:\/\/ckl-website-static.s3.amazonaws.com\/wp-content\/uploads\/2017\/12\/Organisms.png\")
<\/p>\nOrganisms are the combination of molecules that work together or even with atoms that compose more elaborate interfaces. At this level, the components begin to have the final shape, but they are still ensured to be independent, portable and reusable enough to be reusable in any content. <\/span><\/p>\n
Templates<\/h3>\n
![\"\"](\"https:\/\/ckl-website-static.s3.amazonaws.com\/wp-content\/uploads\/2017\/12\/Templates.png\")
<\/p>\nIn this state we stop composing components and begin to set their context. Moreover, the templates create relationships between the organisms and others components through positions, placements and patterns of the pages but it doesn\u2019t have any style, color or component rendered. That\u2019s why it looks like a wireframe.<\/span><\/p>\n
Pages<\/h3>\n
![\"\"](\"https:\/\/ckl-website-static.s3.amazonaws.com\/wp-content\/uploads\/2017\/12\/Pages.png\")
<\/p>\nPages are the navigate parts of the application and it\u2019s where the components are distributed in one specific template. The components get real content and they\u2019re connected with the whole application. At this stage, we can test the efficiency of the design system to analyse if all the components are independent enough or if we need to split them in smaller parts.<\/span><\/p>\n
React + Atomic Design<\/h2>\n
When we started to use Atomic Design within React we had to adjust some rules of the methodology to ensure that components were reused as much as possible, that they were stateless, without styles of positions and very specific margins so to avoid any side effects in the pages of application.<\/span><\/p>\n
So with each new component we asked ourselves: \u201cAre these components generic enough to avoid specificity and\/or repeated code in whatever context they are used?\u201d<\/span><\/p>\n
So we were able to write a few rules:<\/span><\/p>\n
- \n
- The Atomic Design should have a file of <\/span>variables<\/b> and it must be imported by each component;<\/span><\/li>\n
- The <\/span>atoms<\/b> should be written without margins and positions;<\/span><\/li>\n
- Only the <\/span>molecules<\/b> and <\/span>organisms<\/b> can set the positions of atoms, but these stacks can\u2019t have any styles of margins and positions;<\/span><\/li>\n
- Templates <\/b>have only one function: to set the grid of pages but never positions of specific components;<\/span><\/li>\n
- Pages render the components with a template defined and it\u2019s here that the <\/span>Atomic Design will be connected to the rest of the application;<\/span><\/b><\/li>\n<\/ol>\n
Let\u2019s code<\/span><\/h2>\n
What I will show here is everything in a boilerplate on GitHub<\/a>,<\/strong> which you can test and then start your projects using Atomic Design, so let’s do it:<\/p>\n
–<\/p>\n
To build a UI LIbrary we used an awesome tool called Storybook<\/a><\/span>, which is a great ally to the Atomic Design in React (you can use it for the React Native<\/a> and Vue too), it allows to render the components and list all states\/variations of one.<\/span><\/p>\n
With the Storybook installed the folder structure will look like this:<\/span><\/p>\n
![\"\"](\"https:\/\/ckl-website-static.s3.amazonaws.com\/wp-content\/uploads\/2017\/12\/path.png\")
<\/p>\nNote that inside of the button component there is a file called \u2018index.js\u2019 which is the component itself, the \u2018styles.css\u2019 is the style that will be imported by CSS Modules (here we\u2019ve used the BEM CSS inside the structure; I recommend reading the article \u2018CSS Architecture with ReactJS<\/a>\u2019) and the \u2018stories.js\u2019 is the file that will import the component into the Storybook, which looks like this:<\/span><\/p>\n
![\"\"](\"https:\/\/ckl-website-static.s3.amazonaws.com\/wp-content\/uploads\/2017\/12\/button.png\")
<\/p>\nEach ‘add ()’ function is a variation of the component and it is the best approach to describe each state individually rather than a single function, so it becomes easier to highlight and control each one of them. So if you describe all the component variations , the Storybook should look like this:<\/span><\/p>\n
![\"\"](\"https:\/\/ckl-website-static.s3.amazonaws.com\/wp-content\/uploads\/2017\/12\/Storybook.png\")
<\/p>\nAnd the coolest part of the Storybook is that you can add some \u2018addons\u2019, such as the Storybook Info<\/a>, which does awesome things like: story source, props types, defaults values and which values are required or not.<\/span><\/p>\n
![\"\"](\"https:\/\/ckl-website-static.s3.amazonaws.com\/wp-content\/uploads\/2017\/12\/proptypes.png\")
<\/p>\nConclusion<\/span><\/h2>\n
At the end of project, we reached the initial goals and we believe we left a good legacy, a structure which ensures that the project can grow and that other developers can understand the architecture quickly. Maybe we initially spent some extra time writing stories and etc, but the more the project grows, the more the benefits make clear why we should use such architecture.<\/span><\/p>\n
However we could see that this architecture probably doesn\u2019t work for every project because it depends on several factors. The main one is that the design needs to be thought in the same way as the development: <\/span>in an atomic way<\/b>. But the integration between design and development is a point that every project wants to reach, so it becomes a very positive point for <\/span>Atomic Design.<\/b><\/p>\n
References<\/h3>\n
Boilerplate on GitHub<\/strong><\/a><\/p>\n
CSS Architecture with ReactJS<\/a><\/p>\n
Atomic Web Design<\/a><\/p>\n
Patternlab<\/a><\/p>\n
- The <\/span>atoms<\/b> should be written without margins and positions;<\/span><\/li>\n
- Lack of precision in estimating development time;<\/span><\/li>\n