Приложение, которое я разрабатываю, изначально было построено с помощью Flux.
Однако со временем приложение стало сложнее поддерживать. Было очень большое количество действий. И обычно одно действие прослушивается только в одном месте (магазине).
Действия позволяют не писать весь код обработчика событий в одном месте. Итак, вместо этого:
store.handleMyAction('ha')
another.handleMyAction('ha')
yetAnotherStore.handleMyAction('ha')
Я могу написать:
actions.myAction('ha')
Но я никогда не использую действия таким образом. Я почти уверен, что это не проблема моего приложения.
Каждый раз, когда я вызываю действие, я мог бы просто вызвать store.onSmthHappen вместо action.smthHappen.
Конечно бывают исключения, когда одно действие обрабатывается в нескольких местах. Но когда это происходит, кажется, что что-то пошло не так.
Как насчет того, чтобы вместо вызова действий я вызывал методы прямо из хранилища? Не будет ли мое приложение таким гибким? Нет! Происходит просто переименовать (за редким исключением). Но какой ценой! При всех этих действиях становится намного сложнее понять, что происходит в приложении. Каждый раз при отслеживании обработки сложных действий мне приходится находить в магазинах, где они обрабатываются. Затем в этих Store я должен найти логику, которая вызывает другое действие. И так далее.
Теперь я прихожу к своему решению:
Есть контроллеры, которые вызывают методы из хранилищ напрямую. Вся логика как обрабатывать действие находится в Магазине. Также сохраняет вызовы WebAPI (как обычно одно хранилище, относящееся к одному WebAPI). Если событие должно обрабатываться в нескольких хранилищах (обычно последовательно), то контроллер обрабатывает это, организуя промисы, возвращаемые из хранилищ. Некоторые из последовательностей (обычно используемые) в частных методах сами по себе. И метод контроллеров может использовать их как простую часть обработки. Поэтому я никогда не буду дублировать код.
Методы контроллера ничего не возвращают (односторонний поток).
На самом деле контроллер не содержит логики как обрабатывать данные. Это только указывает где и в какой последовательности.
Практически полную картину обработки данных вы можете увидеть в Магазине. В магазинах нет никакой логики относительно того, как взаимодействовать с другими магазинами (с потоком это похоже на отношение "многие ко многим", но только через действия). ). Теперь магазин представляет собой высокосвязный модуль, отвечающий только за логику модели предметной области (коллекции).
Основные (на мой взгляд) преимущества флюса все же здесь.
В результате есть Магазины, которые являются единственным источником данных. Компоненты могут подписываться на Магазины. И компоненты вызывают те же методы, что и раньше, но вместо actions использует controller. Взаимодействие с React вообще не изменилось.
Кроме того, обработка событий становится более очевидной. Теперь я могу просто посмотреть на обработчик в контроллере и все становится понятно, да и отлаживать намного проще.
Вопрос в том:
Почему действия были созданы в потоке? И какие у них преимущества, которые я упустил?
