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

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

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

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

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

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

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

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

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

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

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

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