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

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

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

Такие новые функции обычно относятся к одной из трёх категорий:

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

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

редюсер (reducer): любая функция с сигнатурой (state, action) -> newState (может использоваться как аргумент Array.prototype.reduce)
корневой редюсер (root reducer): функция, передаваемая первым аргументом в createStore. Единственная часть логики, обязанная иметь сигнатуру (state, action) -> newState.
срезовый редюсер (slice reducer): обрабатывает обновления конкретной части состояния, обычно передаётся в combineReducers
функция-обработчик (case function): обрабатывает логику обновления для конкретного экшена. Может быть редюсером или требовать дополнительных параметров.
редюсер высшего порядка (higher-order reducer): функция, принимающая редюсер и/или возвращающая новый редюсер (например, combineReducers или redux-undo)

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

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