Optimizing React Native Project Structure: The Modular Architecture Approach
Tags: projectstructure, react, modulararchitecture, reactnative
Published: 2023-10-06 11:19:04

---
title: Optimizing React Native Project Structure: The Modular Architecture Approach
published: true
date: 2023-10-06 10:48:45 UTC
tags: projectstructure,react,modulararchitecture,reactnative
canonical_url: 
---

![](https://cdn-images-1.medium.com/max/1024/1*wvATmxlb6ijyGJPAMGEB5A.jpeg)

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:

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

&nbsp;

### 🙌🏻 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.

```diff
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.

&nbsp;

> **_Module Structure:_**

> _Domain (_ **_An instrument in the hands of a conductor_** _ — Business logic of the module)_

> _Store (_ **_Conductor_** _ — Module control logic)_

> _UI (_ **_Presentation_** _)_

&nbsp;

### 🪄 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

```diff
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)

&nbsp;

### 💾 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:**

```diff
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

&nbsp;

### 🖼️ UI lvl

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

```diff
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!