Decoding Web Layout Using Atomic Design — Part 2

by Sambhav Jain

This article is a continuation of part two on my series of Simplifying Developer Experience with Atomic Design. In this article, we will go deeper into decoding a web page and break it up in terms of Atomic Design.

To understand Atomic Design and its properties further, we are going to take a page layout of product hunt home page. Let’s assume, we are working as a UI engineer at product hunt, and we are given the task of creating the web layout of the given design for the home page.

Home page of Product Hunt website

As a first step we will break this layout from a Top to Bottom approach in terms of atomic design.

Template

Templates, are page level objects that place components into a layout. First, we will find out the major objects which will constitute this layout.

Bird’s-eye view of a template

Looking from a bird’s-eye view perspective, we can divide our template into these major components, marked with red in the above image. Our home template will look like the below code.

As we can see, a template is only the wireframe of our layout, consisting of other components, such as Header, MainContainer & AsideContainer.

Organisms

Organisms are complex structure components, which can be a combination of other smaller organisms, molecules and atoms.

Top-level organisms in this page are Header, MainContainer and AsideContainer.

• Header -> Owns individual responsibility and has a specific functionality. It contains molecules and atoms, which we will see in the below sections.
• MainContainer -> Contains a list of product posts, Heading and a dropdown.
• AsideContainer -> Contains a group of stories, which are themselves an organism.

Organisms can be a combination of other organisms as well.

• Here, MainContainer is a parent organism, containing ListContainer as a child organism, along with Heading and SingleSelect.
• ListContainer is acting as an individual organism, which can be reusable in other similar structure as well. It internally contains Card component as its primary child component.
• Card Component is our primary component which is used in ListContainer, StoriesContainer as a child component. It has an Image, description, buttons as atoms.

Molecules & Atoms

Smallest Entity in a layout are Atoms, and combination of one or more such atoms are molecules.

• TextInput is a combination of Icon and Input element.
• NavGroup is a group of NavLink, which are group of atoms individually.
• Button, Text, Links, Icon, Image will be form our atoms.

Final Version

From a simple figma design, we have divided our layout into Organism, Molecules and atoms which our much more re-usable and scalable as we go along than just plain html, css code. Our final version of layout will look like the below image.

Decisions, while creating a component:

• Start small, Start specific > Sticking only with the use case required for creating a component is beneficial. Adding unnecessary functionality is adding more complexity which is not required at the time. Add functionality, only when required.
• Start Rigid. Add flexibility as required > Keeping a component rigid (having specific features and fixed props) is simpler to create and easier to understand, less maintenance, & more consistent as compared to the flexible component which is dependent on the context where it is being used.

Folder structure

Structuring large application is really important for maintenance and scalability. Below is the structure I have used for creating this layout.

• UI > Component layer divided into Templates, Organisms, Molecules and Atoms.
• pages > Where all the data injection is happening.
• routes > Routing setup of the application.
• store > Global store, where all the individual pages store is connected.

Please find the Github link here, for the folder and code structuring.

Final Note

While thinking of a layout breakup, thinking Atomically is a great way to de-structure your complex app. As more and more complexity is increasing, thinking about smaller structures and making them re-usable is a wise way to develop. But, knowing when to create a new component and adding functionalities is as much important. Since we also do not want to add complexity to our development effort. Maintaining readability is equally important for developer friendliness. Again, I’m emphasising starting small and specific, that is the key.