It lasts for a couple of years, and I’m using an Atomic Design methodology to structure the components in the projects or products. So, that is why I want to discuss this topic.
What is the Atomic Design about?
Atomic Design is a methodology in UI to develop an optimal design system for a project or a product. This methodology’s concept was formulated by Brad Frost, and the main purpose of this methodology is to focus on components than pages of UI.
Nowadays, a lot of web applications were created using a component-oriented framework such as React.js, Vue.js, Angular or Svelte. So, with these frameworks creating reusable components is the main pattern to develop a web app.
However, having a components directory and storing all components of the project there could be uncomfortable with the lapse of time after project growth.
So, Atomic Design provides some principles and stages of component development.
Some principles
Atomic Design methodology in development is associated with Component Driven Development, so, the principles are also.
- First of all, the component has to be reusable
- The component has to be independent and encapsulated
- The component has to be focused on one piece of logic
- The component has to be easily testable
If we look at these principles, we can notice some similar meaning with SOLID principles.
It means if we keep our component independent and encapsulated our component will adhere to the Open-Closed Principle of SOLID. Also, if we keep our component focused on one piece of logic it means that our component has a single responsibility which is the first principle of the SOLID. If we can easily reuse our component, it means this component also follows the DRY principle.
What a fantasy! Knowing only one methodology can help us stick to the design principles and use their benefits.
Component development stages
So, by Atomic Design methodology we need to divide our components into next types:
- atoms
- molecules
- organisms
- templates
- pages
Atoms
Atoms are the smallest components, that are built using HTML tags. You can’t decompose them, because atoms are the bricks of the UI. For example, some atom components could be buttons, badges, labels, headings, and so on. Usually, they are stateless, and only encapsulates appearance styles.
Molecules
Molecules are more complex components than atoms. Molecules can be built using atoms, and provide a unified piece of logic. For example, we need to create a navigation bar. So, we can use link atom components, group them together, and this would be our molecule component. Or, we need search input. We use an input atom component, button atom component, and the grouping of these components creates the molecule component.
Organisms
Organisms are complex components that can be built using atoms and molecules. If atoms or molecules can be some abstract pieces, which couldn't have concrete logic or meaning, molecules have a specific meaning. For instance, using some atoms and molecules we can build a header component. We know why do we need the header, and we know how this component should behave.
Templates
Templates are a composition of organisms, molecules, and atoms and provide a concrete UI structure. If we have a specific section in our project as ‘Latest news’ that could be rendered on several pages, this section has to be a template. So, we can simply reuse this template, and not be afraid that something could be messed up. Because all things that we need from this section are encapsulated inside of it.
Pages
Pages are complex of templates and other components with content. So, if we have some bugs or another mess in UI, we can easily locate that and fix it in a related component.
Conclusion
This methodology is really helpful to create some large UI. Because it increases code reusability, maintainability, it makes debugging easier and improves composability, so you can just extend a component for a specific use-case.
However, to keep your components clean, you have to avoid writing business logic in your components. Business logic should be placed at least at a store, better it should be decomposed for some repositories, services, and so on. UI should be UI, it’s a view layer of an app, left logic to the model, but it is an another story.
Top comments (0)