Разделение логики редьюсеров

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

Так как редьюсер Redux — просто функция, то это же концепция применима и к нему. Вы можете вынести часть логики редьюсера в другую функцию и вызвать эту новую функцию из родительской функции.

Эти новые функции обычно попадают в одну из трех категорий:

1. Небольшие вспомогательные функции, содержащие некоторый повторно используемый фрагмент логики, необходимый в нескольких местах (который может или не может быть фактически связан со специфической логикой бизнеса)
2. Функции для обработки конкретного случая обновления, которым часто требуются параметры помимо типичной пары (state, action)
3. Функции, которые обрабатывают все обновления для заданного среза состояния. Эти функции обычно имеют типичную подпись параметра (state, action)

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

• редьюсер: любая функция с подписью (state, action) -> newState (то есть любая функция, которая может использоваться в качестве аргумента для Array.prototype.reduce)
• корневой редьюсер: функция редьюсера, которая фактически передается в качестве первого аргумента createStore. Это единственная часть логики редьюсера, которая обязательно должна иметь подпись (state, action) -> newState
• редьюсер среза: редьюсер, который используется для обработки обновлений одного конкретного среза дерева состояния, обычно путем передачи его combineReducers
• функция случая: функция, используемая для обработки логики обновления для конкретного действия. Она может фактически быть функцией редьюсера, или ей могут потребоваться другие параметры для правильной работы.
• редьюсер высшего порядка: функция, которая принимает функцию редьюсера в качестве аргумента и/или возвращает новую функцию редьюсера в результате (например, combineReducers, или redux-undo)

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

Разбиение сложного процесса на более мелкие и понятные части обычно описывается термином функциональное разложение. Этот термин и концепция могут быть применены к любому коду. Однако в Redux очень часто используется структура логики редьюсера с помощью подхода № 3, где логика обновления делегируется другим функциям на основе среза состояния. Redux называет эту концепцию составление редьюсеров, и это, безусловно, наиболее широко используемый подход к структурированию логики редьюсеров. Фактически, это так распространено, что Redux включает вспомогательную функцию под названием combineReducers(), которая специально абстрагирует процесс делегирования работы другим функциям редьюсеров на основе срезов состояния. Однако важно отметить, что это не единственный используемый шаблон. На самом деле, вполне возможно использовать все три подхода для разделения логики на функции, а это, как правило, хороший подход. В разделе «Рефакторинг редьюсеров» показаны некоторые примеры этого на практике.