У меня есть сценарий, когда мне кажется, что мне нужно отправить действие в ответ на другое действие, и я не знаю, как лучше его разобраться.
Действие отправляется в ответ на HTTP-ответ, например:
type: 'auth'
data: { username: 'tom' }
Поскольку этот ответ был успешным, я хочу отправить действие, чтобы отправить пользователя на домашнюю страницу:
type: 'navigate'
date: { where: 'home' }
Это кажется мне разумным потоком: это случилось, поэтому теперь я хочу, чтобы это произошло. Проблема в том, что диспетчер потока не позволяет этого, поскольку мы все еще находимся в цикле отправки. Я понимаю, почему отправка во время отправки - плохая идея.
Некоторые люди решили это с несколькими диспетчерами, хотя кажется, что авторы Flux уверены, что вам нужен только один, и вам нужно переосмыслить свои магазины.
Я не вижу, как я мог бы реструктурировать свои магазины, чтобы облегчить это, не запутывая намерения. Мой UserStore знает о действиях auth, а мой RouteStore знает о действиях navigate. Любые предложения о том, как магазины могут быть изменены для облегчения этого, будут оценены.
Мне кажется, что setImmediate будет работать, но кажется немного грязным. Я также думаю, что диспетчер, который поставил в очередь действия, мог бы помочь, но я чувствую в своих костях, что это может вызвать неприятные проблемы.
Каков наилучший выход из этого?
Обычно решение этой проблемы состоит в том, чтобы выполнить резервное копирование и посмотреть исходное действие, а также ждать значения, которое вы пытаетесь отправить во втором действии, если требуется производное значение.
Итак, в этом случае вы ответите только на "auth" как в UserStore, так и в RouteStore.
Вы должны оглянуться назад, как вы пытаетесь создать этот поток.
Вы говорите, что вам нужно создать действие в ответ на другое действие, верно? Итак, назовите это "ActionForwarderStore".
В итоге получим такой поток:
AuthAction --> Dispatcher --+--> UserStore
|
+--> ActionForwarderStore --+
|
+--------------------------------------------+
|
+-> Dispatcher -----> RouteStore
Вы видите, что у вас все еще есть кто-то, кто понимает, что AuthAction должен в конечном итоге изменить маршрут? Это ActionForwarderStore. Поскольку Flux предлагает, чтобы каждый Store слушал каждое действие, это знание AuthAction, заканчивающееся в изменении маршрута, может перейти прямо в RouteStore. Вот так:
AuthAction --> Dispatcher --+--> UserStore
|
+--> RouteStore
Помните, что Flux был "создан", чтобы избежать непредсказуемости MVC. Если вы сохраните все изменения маршрута в RouteStore, вам просто нужно посмотреть этот код Store, чтобы понять, какие действия приведут к изменению маршрута. Если вы попытаетесь создать действие в ответ на другое действие, вы узнаете только, что NavigateAction изменяет маршруты, и вам нужно будет посмотреть другие магазины, чтобы проверить, какие из них запускают это действие в ответ на другие.
Это то, что Flux именует как "однонаправленный поток". Легко ловить проблемы таким образом, потому что это единственный поток, разрешенный. Если вы нажмете кнопку и измените маршрут, вы можете точно знать, что действие, которое отправлено кликом, вызывает изменение маршрута, никаких каскадных действий нет.