Redux FAQ: Структура кода

Содержание

Структура кода

Как должна выглядить моя файловая структура? Как я должен группировать генераторы действий и редюсеры в проекте? Где должны быть селекторы?

Поскольку Redux - это просто библиотека хранения данных, у нее нет точного мнения о том, как ваш проект должен быть структурирован. Тем не менее, есть ряд общих паттернов, которые большинство разработчиков Redux склонны использовать:

  • Rails-style: отдельные директории для “действий”, “констант”, “редюсеров”, “контейнеров” и “компонент”
  • Domain-style: отдельные директории для фичи или домена, возможно, с поддиректориями для каждого типа файлов
  • “Ducks”: похож на domain-style, но явно связывающий действия и редюсеры, часто определяя их в том же файле

В целом предполагается, что селекторы определены наряду с редюсерами и экспортируются, а затем повторно используются в других местах (таких как, функции mapStateToProps, асинхронные генераторы действий или саги) чтобы сосредоточить весь код, который знает о фактической форме дерева состояния в файлах редюсеров.

Тогда как, в конечном итоге, не имеет значения, как вы размещаете ваш код на диске, важно помнить, что действия и редюсеры не следует рассматривать изолированно. Допускается (и рекомендуется) для редюсера, быть определенным в одной папке, чтобы реагировать на действия, определенные в другой папке.

Дополнительная информация

Документация

Статьи

Обсуждения

Как я должен разделять логику между редюсерами и генераторами действий? Где должна быть "бизнес-логика"?

Нет определенного четкого ответа на то, какие части логики следует переносить в редюсер, а какие в генератор действий. Некоторые разработчики предпочитают иметь "толстые" генераторы действий, с "тонкими" редюсерами, которые просто берут данные в действии (action) и слепо добавляют их в соответствующее состояние. Другие пытаются подчеркнуть, сохраняя действия, как можно маленькими, и свести к минимуму использование getState() в генераторе действий. (Для целей данного вопроса, другие асинхронные подходы, такие, как саги и обзерваблы, попадают в категорию "action creator")

Этот комментарий красиво подводит итог этого разделения:

Теперь проблема в том, что поместить в генератор действия, а что в редюсер, выбор между толстыми и тонкими объектами действий. Если вы кладете всю логику в генератор действия, вы в конечном итоге остаетесь с толстыми объектами действий, которые в своей основе декларируют обновления состояния. Редюсеры становятся чистыми, глупыми, добавлять, удалять, обновлять эти функции. Они будут легко композируемы. Но не так много бизнес-логики будет там. Если вы размещаете больше логики в редюсерах, вы в конечном итоге имеете красивые, тонкие объекты действия, большая часть вашей логики данных в одном месте, но ваши редюсеры сложнее составлять, т.к. вам может понадобиться информация из других веток. Вы в конечном итоге с большими редюсерами или редюсерами, которые принимают дополнительные аргументы выше в состоянии.

Найти баланс между этими двумя крайностями и вы освоите Redux.

Дополнительная информация

Статьи

Обсуждения

results matching ""

    No results matching ""