Thread by @mobileunderhood

#день4 Про управление side effect в redux парадигме.

Архитектура которая не умеет в side effect это немножко бесполезная архитектура.

В мире Redux.js эсть множество решений этой проблемы. От "умных" Action (github.com/reduxjs/redux-…) до саг (github.com/redux-saga/red…)

Я перепробовал множество вариантов за 4 года практики, но последний год я полностью доволен data-driven side effect.

Идея состоит в том что UI это тоже side-effect. И нет смысла придумывать новый способ выполнения side effect. Так что абсолютно все сервисы я подключаю так же как и UI.

У каждого сервиса есть Props которые описывает то состояние мира который сервис должен обеспечить. Сервис постоянно получает новые Props, смотрит на внешний мир и пытается его поменять так, что бы Props не отличались от внешнего мира.

Мы называем такие сервисы - операторы. Это название привязалось из Kubernetes абстракции которая делает то же самое. (kubernetes.io/docs/concepts/…). Вообще весь Kubernetes это data-driven система, которую интересно рассматривать как пример для вдохновения.

Конкретные примеры. Переход между экранами логина и самим приложением происходит после изменения State, и удобно описывается вот такими пропсами.

Оператор получает 2 подключенных контроллера и переключает их в зависимости от Props.

У него так же есть свой Connector который эти Props формирует. Тестировать оператор можно только в составе всего приложения (руками) так как операторы зависят от конкретных фреймворков.

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

Оператор держит в себе список запросов которые запущены, что бы избежать повторов. Когда в Props появляется новый запрос - оператор запускает его. Когда пропадает - отменяет его если он еще выполняется.

Таких операторов может быть довольно много: Keychain, UserDefaults, GPS, Alert. Все сервисы которые вам могут понадобиться.