Отправка дальнейших действий при обработке действий

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

Действие отправляется в ответ на HTTP-ответ, например:

type: 'auth'
data: { username: 'tom' }

Поскольку этот ответ был успешным, я хочу отправить действие, чтобы отправить пользователя на домашнюю страницу:

type: 'navigate'
date: { where: 'home' }

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

Некоторые люди решили это с несколькими диспетчерами, хотя кажется, что авторы Flux уверены, что вам нужен только один, и вам нужно переосмыслить свои магазины.

Я не вижу, как я мог бы реструктурировать свои магазины, чтобы облегчить это, не запутывая намерения. Мой UserStore знает о действиях auth, а мой RouteStore знает о действиях navigate. Любые предложения о том, как магазины могут быть изменены для облегчения этого, будут оценены.

Мне кажется, что setImmediate будет работать, но кажется немного грязным. Я также думаю, что диспетчер, который поставил в очередь действия, мог бы помочь, но я чувствую в своих костях, что это может вызвать неприятные проблемы.

Каков наилучший выход из этого?

Ответ 1

Обычно решение этой проблемы состоит в том, чтобы выполнить резервное копирование и посмотреть исходное действие, а также ждать значения, которое вы пытаетесь отправить во втором действии, если требуется производное значение.

Итак, в этом случае вы ответите только на "auth" как в UserStore, так и в RouteStore.

Ответ 2

Вы должны оглянуться назад, как вы пытаетесь создать этот поток.

Вы говорите, что вам нужно создать действие в ответ на другое действие, верно? Итак, назовите это "ActionForwarderStore".

В итоге получим такой поток:

AuthAction --> Dispatcher --+--> UserStore
                            |
                            +--> ActionForwarderStore --+
                                                        |
           +--------------------------------------------+
           |
           +-> Dispatcher -----> RouteStore

Вы видите, что у вас все еще есть кто-то, кто понимает, что AuthAction должен в конечном итоге изменить маршрут? Это ActionForwarderStore. Поскольку Flux предлагает, чтобы каждый Store слушал каждое действие, это знание AuthAction, заканчивающееся в изменении маршрута, может перейти прямо в RouteStore. Вот так:

AuthAction --> Dispatcher --+--> UserStore
                            |
                            +--> RouteStore

Помните, что Flux был "создан", чтобы избежать непредсказуемости MVC. Если вы сохраните все изменения маршрута в RouteStore, вам просто нужно посмотреть этот код Store, чтобы понять, какие действия приведут к изменению маршрута. Если вы попытаетесь создать действие в ответ на другое действие, вы узнаете только, что NavigateAction изменяет маршруты, и вам нужно будет посмотреть другие магазины, чтобы проверить, какие из них запускают это действие в ответ на другие.

Это то, что Flux именует как "однонаправленный поток". Легко ловить проблемы таким образом, потому что это единственный поток, разрешенный. Если вы нажмете кнопку и измените маршрут, вы можете точно знать, что действие, которое отправлено кликом, вызывает изменение маршрута, никаких каскадных действий нет.