Over the years of working with React, we've seen a lot of different structures used for organizing components and when we first discovered atomic design by Brad Frost, we felt we found the Holy Grail. If you want to read his e-book, it can be found here.
I wont be covering Templates in this article as we don't use them often, but they can be useful if they apply to your project scope.
Atoms are the simplest form of any component. In chemistry, they are the simplest form of matter and known as the building blocks of matter. In app development, we use them as the building blocks of UI's. An example of an atom component would be a button, or a text input. We cannot break down a button nor a text input any further without compromising their functionality. That's how you know that you have an atom. Below is an example of a generic mobile button component. It was designed and implemented to be capable of receiving multiple properties (props) in order to alter its state, appearance, and behavior, quickly and efficiently, wherever it is implemented.
In chemistry, molecules are groups of atoms bonded together that take on distinct new properties. For instance, water molecules and hydrogen peroxide molecules have their own unique properties and behave quite differently, even though they’re made up of the same atomic elements (hydrogen and oxygen).
In our UI's, molecules are groups of atoms that work together to perform a certain action. Say in our codebase we have created a Button component seen above as well as a TextInput component. If we then put them together, we could create a login form that we can use in a web or mobile application. One TextInput field for the username, another for the password. Then placed below them, you could put the Button component which fires an onPress function, triggering validation and authentication of the username and password that was typed in.
Organisms are the most complex of the three, making up distinct sections of a UI such as the navigation bar of a website or a custom table. In the image below, we have a table component. The first component we can identify is the container around the entire table proving the overall shape and layout of the inner components. In the upper right and lower right corners we have action buttons, a molecule and an atom, respectively. The upper right opens a menu for options, and the lower right navigates to another page to show the rest of the data. A atom in the upper left corner provides the title for the table. Then we have all the tabular data, making another molecule, comprised of a row header with the column labels, and then four rows of data. With this component being made up of multiple atoms and molecules, we have formed a unique organism that we could call LeadsTable.
Pages or Screens
Lastly, we get to the largest component, Pages (web) and Screens (mobile). Pages and Screens are what the user will see and interact with, made up of atoms, molecules, and organisms. It's where you truly test all of the features and functionality of your application and ensure that all the content is in place, all the components are properly rendering and responsive, it's the final form of your UI.
In the root of your project, if you don't have an src folder, I usually make one. Inside the src folder, I make a new folder called components which then will also have three more folder: atoms, molecules, and organisms. Our standard is we use PascalCase specifically for the actual component file, and camelCase for all folders and other files.
This methodology has proven itself time and time again at Innovia. New engineers have been able to quickly pick up on any project, easily locate components as well as read and understand them with some help from TypeScript. Along with accelerated onboarding, having consistent architecture has also helped us write better and more efficient documentation, continuously optimize and update our code, and provide better support to our customers and our own products.