First, what is Atomic Design?<\/b><\/h2>\n
A methodology created initially by Brad Frost, in which he took inspiration from chemistry and brought it to applications and the way to develop. Initially, it focused only on the design and eventually reflected and “revolutionized” front-end architecture as well. In Brad’s own words:<\/span><\/p>\n Atomic design is methodology for creating design systems. There are five distinct levels in atomic design: atoms, molecules, organisms, templates and pages.<\/span><\/p><\/blockquote>\n Atoms<\/b>: are the basic structure of matter, applied to web atoms are like HTML tags, a label, an input or a button.<\/span><\/p>\n Molecules<\/b>: They are a group of atoms put together with basic fundamentals of a unit. They serve as the basis for the design system. For example, a label, input and button together making a form element.<\/span><\/p>\n Organisms<\/b>: They are blocks of our system, where we can group molecules together to form relatively more complex components, a section of the application.<\/span><\/p>\n Templates<\/b>: They are mostly a group of organisms put together to form a final structure, this is where we begin to see the layout in action.<\/span><\/p>\n Pages<\/b>: These are instances of templates where \u201cgaps\u201d are filled with content, resulting in the final view that the user will see.<\/span><\/p>\n I know there are several examples of atomicity out there, so I want to focus on the problems I encountered during my experiments while working with React, showing some concepts and an example of code that you can find linked at the end of the article.<\/span><\/p>\n * Duplicate Behavior (mainly between molecules and atoms)<\/span><\/p>\n * Inability to reuse code between projects<\/span><\/p>\n * Lack of visibility and understanding of component state<\/span><\/p>\n * Great impact on development time by creating more components than needed<\/span><\/p>\n * Difficult code maintainability due to lack of standardization<\/span><\/p>\n Well, let\u2019s talk about each item separately, starting with: <\/span>Duplicate Behavior<\/b>. What I\u2019ve noticed looking at various projects is that even though they are different code, components often have the same behavior. As in the case of forms components, where we tend to create a component for each form of the application (form-client, form-company, form-xxxx,\u2026) and they perform the tasks in a similar way. Why not create a single, more detailed and worked form component that can abstract all of these components? It’s easier to avoid abstraction and simply implement specific behavior in duplicated components, and that’s what greatly impact reusability within a project.<\/span><\/p>\n Inability to reuse code between projects<\/b> is a very important thing for a company and its developers. Does rewriting all the code with each project mean your code is not good enough to use again? The problem I see here is related to where to put your application\u2019s business rule. Continuing with the forms example above, your component should not be aware of the backend API let alone fetch the data. As stated earlier, components are \u201cdumb\u201d elements. Your entire business rule, functions that are \u201cinjected\u201d into your components, must come from the business rule layer (pages, containers, services). This way you can move your code between projects, taking only what interests you.<\/span><\/p>\n The lack of visibility and understanding of component state<\/b> is very particular and will vary widely among developers. Using a list of users as an example, I want to highlight that it may be hard for another developer to understand the component’s usage and behavior just by its name if you add other things to the component, like API requests to fetch users information and\/or handling the Redux state for it. At that point, we lost all the intuitiveness of the component as it became a piece of application, no longer a simple component.<\/span><\/p>\n Considering that you develop your components by duplicating behavior or injecting business rules into them, at some point on the project you may have a <\/span>big impact on development time<\/b> by creating more components than necessary. Why do I say this? Because there are situations, that happen more often than we want, in which small fixes impact in changes on dozens of components or even API changes to break the entire application, and that can cause a giant rework during the fix. In addition to it, if your projects are reusable, planning will give you much more accuracy on time and scope management.<\/span><\/p>\n Last but not least, <\/span>difficult code maintainability due to lack of standardization<\/b> is something that happens all the time, since every project gets refactored, and every week there is a new library available, a React update (now all components have hooks, now each one has useState), etc. Don\u2019t get me wrong, code must be updated, but before that, it must be thought through, standardized and then evolved.<\/span><\/p>\n![\"atomic-react\"](\"https:\/\/ckl-website-static.s3.amazonaws.com\/wp-content\/uploads\/2019\/12\/blogpost-atomic-react-02.png\")
Problems<\/b><\/h2>\n
OK! What tips can I share?<\/b><\/h2>\n
![\"pages\"](\"https:\/\/ckl-website-static.s3.amazonaws.com\/wp-content\/uploads\/2019\/12\/blogpost-atomic-react-01.png\")
<\/p>\n