Why I migrated to using Atomic Design in my React Native project… and what challenges I faced
An overview of my experience discovering and switching over to Atomic Design in a React Native project.
First, I’ll introduce my experience, the project applied in this scenario, and why I was interested in adopting Atomic Design. Next, I’ll explain what steps I took to migrate over to the Atomic Design pattern. Finally, I’ll discuss what challenges I faced when switching over to Atomic Design and what I’d do differently.
So let’s begin…
My background
I’m a self-taught developer who’s been using Javascript for almost four years and React for about two. Only recently I took it upon myself to learn React Native and try out mobile development.
The project
The project being discussed is an educational app designed to help Hebrew language learners with verb conjugations. It has 3 main features and some other supporting ones.
The front-end of this project was jumpstarted using Expo and depends on packages such as react-navigation, react-native-gesture-handler, react-native-async-storage, and more.
Its main features include:
1. A Search Engine, which allows the user to find full conjugation tables of any verb in the language by typing just one form (or a translation) of that verb into the search bar.
2. An Interactive Learning Game, which enables the user to practice verb conjugations by answering multiple choice (drag and drop) questions, writing questions, and matching questions (to determine which conjugation belongs to which pronoun, ex. he ran).
3. Written Lessons, which provide the user with educational content to learn how to appropriately conjugate each verb pattern.
The supporting features include:
1. A Quick Play Screen which can fast track the user to practicing a given verb set.
2. A Settings Screen for the user to manage their personal details and/or teaching language preference.
I took interest in creating this project after learning Hebrew myself and discovering how troubling verb conjugations can be for some people. I noticed that big players like Duolingo don’t have well-articulated Hebrew learning options and thought it might even become ab effective real-world application. In addition, I marveled at the tabular nature of verb conjugations in many languages, compared their nature to computer science concepts such as objects, and thought it would be an interesting project to bring to fruition.
Why Atomic Design?
Originally, my project directory was structured as so:
In the beginning, it worked fine. I was building modules with a couple of import statements from various parts of the project. Then, I started building more and more components. More and more screens. More reducers. More state management. I started incorporating more API requests and more business logic became involved. Sooner or later, I decided it was time to clean up my code and I realized I had a huge organizational issue. Don’t get me wrong, the code worked. It ran without exceptions, but if another developer were to come and read it, they’d take a long time finding their way. Variable names were indescriptive, modules were in unexpected places, and I wasn’t following any official casing conventions. In clean code terms, it was a disaster.
After researching a bit on how to structure a React Native project I found this article on atomic design. I tweaked their teachings a bit to fit my cause but after a ton of offline work (which was a huge mistake, though I’ll get more into that later), my folder structure went from looking like the above picture to this:
At times the migration was frustrating but once all of the refactorings were over, it was a huge relief. I believe that the readability of this source code has increased dramatically. Components can now be found easily, import and export statements are more concise, and variable and directory names have become clear. Atomic Design provides for more of a professional feel to a project by guiding a developer to neatly organize modules into neatly organized directories.
The challenges
Here are some of the challenges I faced when migrating to the atomic folder structure.
1. Deciding which components go in which folder. Naturally, you’d assume it’s obvious, but when push comes to shove, it’s not always clear whether a component should go into atoms, molecules or organisms. Is it using native components only? Is it importing another atom? Does it have a physical UI or is it more of a template?
2. Determining when to modularize business logic and when to keep it in a component. Reducers were modularized, naturally, but certain initial states which utilized service util functions needed to stay within the component or would cause require cycles. Ever hear of a require cycle? Because until now, I hadn’t…
What I’d do differently
There’s one thing I’d do differently. TEST after changing anything. I decided to go a week offline without testing anything. And I paid for it in the end. When I finally ran my code, I was sidetracked with numerous require cycle warnings, type errors, and other exceptions I’d never seen before. Only after ciphering through all of these was I able to enjoy the benefits of atomic design.
Finally, I definitely recommend this pattern for any of your React Native projects. Thank you.
