Optimizing React Native Project Structure: The Modular Architecture Approach

In this article, I will share my experience of structuring projects, which I have been successfully using for three years in my React Native projects. I think that structuring a project by file types is not the best approach, although it works well in some situations. My team and I use something similar to modular architecture for our projects, and we want to share it with you!

🚩 Problem

There are several approaches to creating the structure of client applications. The most common, but not the most convenient one, is splitting the project by file type. The main problem is that the logic of one module is “smeared” over the whole project. In this approach, the structure usually looks like this:

api
components
containers
- HomeContainer.tsx
- ProfileContainer.tsx
- SettingsContainer.tsx
store
App.jsx

🙌🏻 Solution

More convenient and scalable is the approach of dividing the project by functionality. We call such top-level units, into which the project is divided, modules.

src
- modules
- - auth
- - core
- - users
- - navigation
- - ud-ui

When divided into modules, all components and logic are next to each other. It is easier to work with such a project: it is easier to navigate the structure, delete and refactor modules, it is easier to see the overall picture of functionality, and there is less chance of interfering with each other during development. Functionality does not always mean business logic. There are functional modules, such as core, ud-ui, which are not tied to business logic.

Module Structure:

Domain ( An instrument in the hands of a conductor  — Business logic of the module)

Store ( Conductor  — Module control logic)

UI ( Presentation )

🪄 Domain lvl

Typically, this layer contains interfaces, model descriptions, services to query the API, or business logic that is not related to a specific view (UI)

Structure of the Domain layer

enums
- UserRoleEnum.ts
interfaces
- User.ts
repositories
- UserRepository.ts
resources
- UserResource.ts

What can be stored at the Domain level?

• Enums
• Interfaces
• Services
• Helpers
• Resources and Repositories (API)

💾 Store lvl

This layer is where the application is managed and interacts with the Domain layer for API calls and changes to the Store. Example of Store-level structure using Redux-Toolkit:

entities
- index.ts
- selectors.ts
- actions.ts
edit
- ...
other-stores
- ...
reducer.ts
selectors.ts

Entities Store

Usually, a separate store called “entities” is used to store data. This is a kind of database for the client application to store entities of the same type. The other stores use identifiers if you need an entity that has already been loaded. So, if an entity is changed, it is changed in one place  — entities store, and the rest of the program picks up the changes because it actually uses a reference to one common object.

Other stores

Usually refers to individual pages or time-consuming actions, for example:

• edit  — user edit page
• index  — user list page
• new  — user creation page

🖼️ UI lvl

The UI layer contains elements related to data presentation, such as components, screens and hooks. Usually, the layer is divided as follows:

screens
- profile
- - index.tsx
- - style.ts
- ...
components
- users-list
- - index.tsx
- - style.ts
- ...
hooks
- useUserForm.ts
- ...

Screens

This folder contains components that are directly assigned in routing, i.e., they are screens or pages in the navigation structure of the application.

Components

Components that relate to the module’s business logic. Can be used outside the module but are necessarily inside its structure

Divide and rule!