Как лучше всего использовать чистую и синхронную логику при использовании React с Redux и Redux-Saga?

Question

После того, как ранее я использовал Redux-Thunk, я играл с Redux-Saga в последнее время. До сих пор я люблю его для обработки асинхронных задач, таких как сетевые запросы. Таким образом, при использовании саг я обязательно добавлю код с асинхронной логикой в ​​саги. Тем не менее, я немного не уверен, куда поместить остальную часть синхронной логики. Я спорю, стоит ли мне оставлять их в редукторах или действиях или создавать саги для них.

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

Использование Sagas для синхронной логики:

1. Счетчик компонентов отправляет START_INCREMENT действие.
2. START_INCREMENT регистр редуктора выполняется и просто возвращает старое состояние.
3. Сага, которая наблюдала START_INCREMENT бега и put действие INCREMENT с полезной нагрузкой incrementNumber.
4. INCREMENT регистр редуктора выполняется и принимает текущий счетчик состояний, добавляет incrementNumber и возвращает новое состояние.

Использование редукторов для обработки синхронной логики:

1. Счетчик компонентов отправляет INCREMENT действие с incrementNumber полезной нагрузкой.
2. INCREMENT регистр редуктора выполняется и принимает текущий счетчик состояний, добавляет incrementNumber и возвращает новое состояние.

Использование действий для обработки синхронной логики:

1. Компонент счетчика отправляет INCREMENT создателю действия с incrementNumber в качестве параметра.
2. Создатель действия возвращает действие INCREMENT действие с count полезной нагрузкой. Это обновленный счетчик.
3. INCREMENT регистр редуктора выполняется и принимает новый счет, заменяет счет в старом состоянии и возвращает новое состояние.

Для меня есть преимущества и недостатки каждого из этих подходов. Перечислим несколько:

Сага

За

1. Логика в сагах и не разбросана по сочетанию саг и действий / редукторов.

Против

1. Более сложный поток с 2 действиями

Переходники

Плюсы

1. Очень просто

Против

1. Логика будет в 2 местах, асинхронная логика в sagas и логика синхронизации в редукторах
2. Не иметь доступа к другим слоям состояния, если это было необходимо
3. Редукторы должны быть чистыми, и мы не можем использовать побочные эффекты, такие как Browser или DOM API

Actions Creators

За

1. Иметь доступ к другим частям состояния, если необходимо, используя redux-thunk
2. Может добавлять другой код побочного эффекта в действия, например, браузер или API DOM

Против

1. Логика будет в 2-х местах, асинхронная логика в сагах и логика синхронизации в действиях
2. Сложнее проверить

Я склоняюсь к использованию Sagas для всех создателей асинхронной логики и действий для всей логики синхронизации, а затем поддерживаю редукторы. Имеет ли этот подход смысл или есть лучший способ обработки синхронной логики в redux-saga?

Спасибо!