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

Содержание

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

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

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

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

Стиль Rails: отдельные папки для «действий», «констант», «редукторов», «контейнеров» и «компонентов»
Стиль по областям: отдельные папки для каждой функции или области, возможно, с подпапками для каждого типа файла
«Утки»: подобно стилю по областям, но явно связывает действия и редукторы, часто определяя их в одном файле

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

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

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

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

FAQ: Действия — «соответствие 1:1 между редукторами и действиями?»

Статьи

Обсуждения

Как следует разделить логику между редукторами и создателями действий? Куда поместить «деловую логику»?

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

Этот комментарий прекрасно суммирует эту дихотомию:

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

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

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

Статьи

Обсуждения