Wysyłanie dalszych działań podczas obsługi działań

Question

Mam scenariusz, w którym mam ochotę wysłać akcję w odpowiedzi na inną akcję i nie wiem, jak najlepiej to rozwiązać.

Powództwo zostało wysłane w odpowiedzi na odpowiedzi HTTP, coś jak:

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

Bo reakcja przebiegła pomyślnie, chcę wysyłką akcję wysłać użytkownikowi na stronie głównej:

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

Wydaje mi się to rozsądnym posunięciem: stało się to, więc teraz chcę, żeby to się stało. Problem w tym, że dyspozytor strumienia nie pozwala na to, ponieważ nadal jesteśmy w cyklu wysyłki. Rozumiem, dlaczego wysyłanie podczas wysyłki jest złym pomysłem.

Niektórzy ludzie rozwiązali to z wieloma dyspozytorami, podczas gdy wydaje się, że autorzy Flux są pewni, że potrzebujesz tylko jednego i że musisz przemyśleć swoje sklepy.

Nie widzę sposobu, w jaki mogłem zrestrukturyzować swoje sklepy, aby to ułatwić, nie zaciemniając intencji. Moje UserStore wie o działaniach auth, a moje RouteStore wie o działaniach . Sugerowane są wszelkie sugestie, w jaki sposób można by zmienić sklepy, aby to ułatwić.

Czuję się jak setImmediate będzie działać, ale wydaje się nieco brudny. Myślę też, że dyspozytor, który stał w kolejce, może pomóc, ale mogę poczuć w moich kościach, że może to spowodować nieprzyjemne problemy.

Jakie jest najlepsze wyjście z tego?

Answer 1

Zazwyczaj rozwiązaniem tego problemu jest utworzenie kopii zapasowej i obejrzenie oryginalnej akcji oraz oczekiwanie na wartość, którą próbujesz wysłać w drugim działaniu, jeśli wymagana jest wartość pochodna.

W tym przypadku odpowiedziałbyś tylko na "auth" zarówno w sklepie z użytkownikami, jak i w sklepie RouteStore.

Answer 2

Powinieneś sprawdzić, jak próbujesz utworzyć ten przepływ.

Mówisz, że musisz utworzyć akcję w odpowiedzi na inną akcję, prawda? Nazwijmy to "ActionForwarderStore".

Skończymy z przepływem tak:

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

Widać, że nadal masz kogoś, kto rozumie, że AuthAction powinien skończyć zmianę trasy? To jest ActionForwarderStore. Ponieważ Flux sugeruje, że każdy Sklep słucha każdej Akcji, ta wiedza o AuthAction kończąca się zmianą trasy może przejść bezpośrednio do RouteStore. W ten sposób:

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

Pamiętaj, że Flux został "stworzony" w celu uniknięcia nieprzewidywalności MVC. Jeśli wszystkie zmiany trasy zostaną zmienione na RouteStore, wystarczy spojrzeć na ten kod sklepu, aby dowiedzieć się, jakie działania spowodują zmianę trasy. Jeśli podejmiesz próbę utworzenia akcji w odpowiedzi na inną akcję, będziesz wiedział tylko, że NavigateAction zmienia trasy, a będziesz musiał spojrzeć na inne sklepy, aby sprawdzić, które z nich wyzwalają tę akcję w odpowiedzi na inne.

To jest to, co Flux określa jako "przepływ jednokierunkowy". W ten sposób można łatwo złapać problemy, ponieważ jest to jedyny dozwolony przepływ. Jeśli klikniesz przycisk i zmienisz trasę, możesz mieć pewność, że akcja, którą wywołane kliknięcie powoduje zmianę trasy, nie powoduje żadnych akcji kaskadowych.