Оптимизация структуры React/React-Native проекта: Подход с использованием модульной архитектуры

В этой статье я поделюсь своим опытом структурирования проектов, который я успешно использую уже три года в своих проектах на React Native. Я считаю, что структурирование проекта по типам файлов - не самый лучший подход, хотя в некоторых ситуациях он хорошо работает. Я и моя команда используем нечто похожее на модульную архитектуру для наших проектов, и мы хотим поделиться этим с вами!

🚩 Проблема

Существует несколько подходов к созданию структуры клиентских приложений. Самый распространенный, но не самый удобный - разделение проекта по типам файлов. Основная проблема заключается в том, что логика одного модуля "размазывается" по всему проекту. При таком подходе структура обычно выглядит следующим образом:

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

🙌🏻 Решение

Более удобным и масштабируемым является подход, при котором проект делится по функциональности. Такие единицы верхнего уровня, на которые делится проект, мы называем модулями.

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

При разделении на модули все компоненты и логика находятся рядом друг с другом. Работать с таким проектом проще: легче ориентироваться в структуре, удалять и рефакторить модули, проще видеть общую картину функциональности, меньше шансов помешать друг другу в процессе разработки. Функциональность не всегда означает бизнес-логику. Существуют функциональные модули, такие как core, ud-ui, которые не привязаны к бизнес-логике.

Структура модуля:

Domain (бизнес-логика модуля)

Store (логика управления модулем)

UI (представление)

🪄 Domain

Как правило, этот слой содержит интерфейсы, описания моделей, сервисы для запросов к API или бизнес-логику, не связанную с конкретным представлением (UI).

Структура

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

Что внутри?

• Enums

• Interfaces

• Services

• Helpers

• Resources and Repositories (API)

💾 Store

На этом уровне происходит управление приложением и взаимодействие с уровнем Domain для вызова API и внесения изменений в магазин. Пример структуры уровня Store с использованием Redux-Toolkit:

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

Entities

Обычно для хранения данных используется отдельный стор, к примеру "entities". Это своего рода база данных для клиентского приложения, в которой хранятся сущности одного типа. Таким образом, если сущность изменяется, она изменяется в одном месте - в сторе сущностей, а остальная часть программы подхватывает изменения, поскольку фактически использует ссылку на один общий объект.

Другие сторы

Обычно относятся к отдельным страницам или трудоемким действиям, например:

• edit — user edit page

• index — user list page

• new — user creation page

🖼️ UI

Слой пользовательского интерфейса содержит элементы, связанные с представлением данных, такие как компоненты, экраны и хуки. Обычно этот слой делится следующим образом:

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

Screens

Эта папка содержит компоненты, которые используются в вашем навигаторе, то есть являются экранами или страницами в навигационной структуре приложения.

Components

Компоненты, относящиеся к бизнес-логике модуля. Обычно там хранятся части экранов или переиспользуемые компоненты внутри конкретного модуля.

Разделяй и властвуй!