Próbuję zbudować aplikację na komputery stacjonarne za pomocą Githuba Struktura elektronowa, który oddziela "główny" proces io.js od procesu "renderowania" JS (BrowserWindow). Uważam, że procesy "główne" / "renderer" są analogiczne do serwera i klienta (daj mi znać, jeśli to pomyłka).
W tej sytuacji jestem zdezorientowany, jak zastosować wzorzec Flux. Niektóre interakcje z UI nie wymagają wysyłania danych do głównego procesu (tj. Przykład listy TODO )
1) Czy to oznacza, że obiekt Dispatchera powinienprzebywać z procesem renderowania? 2) Załóżmy, że główny proces odbiera nadchodzące zdarzenie / akcję z systemu plików. Aby zaktualizować program rozsyłający, czy główny proces musiałby zaimplementować ActionCreator w celu utworzenia akcji, a następnie wysłać działanie za pośrednictwem protokołu IPC / RPC do programu rozsyłającego w procesie renderowania / klienta? 3) Jeśli (2) jest prawdziwe, czy oznacza to, że twórcy akcji i sklepy są również wdrażane po stronie głównej / serwerowej?
Dziwnie jest mieć "Pierwszego respondenta" / "Delegata" w kontekście procesu renderowania.
Odpowiedzi:
0 dla odpowiedzi № 1Ach, trochę więcej czytania pomogło mi to rozgryźć. Flux miał być przede wszystkim wzorcem aplikacji po stronie klienta.
Poniższy diagram ilustruje typowy przypadek użycia oraz sposób, w jaki serwer i powiązany z nim stan są nieco odłączone od logiki strumienia po stronie klienta.
Innymi słowy, Flux na kliencie nie rozwiązuje problemuproblem zarządzania stanem i komponentami po stronie web-api. W przypadku aplikacji klienckich ściśle sprzężonych z kodem po stronie serwera (takich jak aplikacje elektronowe, notesy iPython, aplikacje NW.js) rozsądne może być implementowanie modułu dyspozytorskiego podobnego do schematu delegowania Cocoa w wątku UI.