How to Improve your Component Folder Structure with Atomic Design (Part 1)

Intro

When we need to define a new component structure of a React project, one of the first questions that will come to mind is, how do we establish a proper component-folder structure?

Defining a Folder Structure

It’s fairly common that in our projects we tend to use a functionality-based approach in the definition of our component, in which we involve components that represent different sections of our page.

Take this structure from the React docs for example:

common/
  Avatar.js
  Avatar.css
  APIUtils.js
  APIUtils.test.js
feed/
  index.js
  Feed.js
  Feed.css
  FeedStory.js
  FeedStory.test.js
  FeedAPI.js
profile/
  index.js
  Profile.js
  ProfileHeader.js
  ProfileHeader.css
  ProfileAPI.js

As you can see, one of the key aspects of this is that we can’t clearly determine the functionality of these components. Their cohesion and coupling relies solely on the context of the feature, which is OK in certain scenarios, but there is another approach that would allow us a separation of concerns and grant a better reusability of our code.

Atomic Design

We know Atomic Design as a methodology developed to optimize and maximize the development of digital products, as described by its creator Brad Frost.

Atomic Design presents us with a cool design structure that helps us easily identify and define the hierarchy a component should have in its creation.

With this representation, we can define components based on the role their represent within their ecosystem.

In the original definition of Atomic Design, it’s defined the original hierarchy of components is depeer than organisms, but in the context of React. We use less to avoid problems such as prop drilling and prevent adding more complexity to our system.

In this case, we would have an structure represented in the following way:

atoms/
  ...
molecules/
  ...
organisms/
  ...

This structure allows us to mantain a proper order within our components use, if needed, utility folders can be made to add aditional logic. Another important concept to keep in mind, is that, by creating a hierarchical-based structure we prevent prop drilling in our components, which is an amazing quality to have in mind.

Atoms

These structures are the building blocks of our React app, they define and represent the most basic components of our folder structure.

We usually represent these components with buttons, labels, etc. In the context of React, this can be represented by their styles! We can have our own Buttonrepresentation that contains certains styles that define it.

We can see the following example of our atom structure:

atoms/
  Button/
    index.js
    Button.css
    Button.js
  Label/
    ...

This allows us to mantain modular components tied to the their hierarchical representation.

Another great alternative, is using css-in-js to favor the definition of styled-components that make great sinergy within the atoms initial purpose.

Here we can see an example of components that we could consider as an Atom:

And this is how we’d present them in our css-in-js components:

As we can see, this approach grants us another benefit, and that’s that we can split and make our styled-components have a logical-relationship sense within our component architecture. Granting us a better code reliability and architectural sense within our smaller components.

Oh, this is cool

That’s enough for now.

In the next parts of this article we will explore the integration of Molecules and their implementation on a real-project approach that follows current-day software engineering examples.

Read the next part here!

If you like this don’t forget to click the 💚.