jaka jest różnica między tym strumieniem akcji a tym wywołaniem funkcji?

Question

mogę dysponowanie strumienia działania takiego:

{type: 'KILL', payload: {target: 'ogre'}} 

Ale nie widzę, jaka jest różnica pomiędzy posiadaniem metodę na klasę ludzi (owijanie sklep), jak ten,

People.kill('ogre') 

JEŚLI Ludzie są jedynym odbiorcą akcji?

widzę, że strumień dyspozytor daje mi dwie zalety (ewentualnie)

1. z „zabić” metoda może być transmitowany do wielu nieznanych odbiorników (dobre!)
2. Dyspozytor daje mi Mądry do zaloguj cały ruch akcji (również dobrze!)

Może to być dobre, ale czy są jakieś inne powody, których mi brakuje?

To, czego nie widzę, polega na tym, że umieszczanie działań w postaci obiektów JSON, nagle wymusza lub pomaga w "jednokierunkowym" przepływie komunikacji, który czytam wszędzie, jest wielką zaletą działania i strumienia.

Wygląda na to, że nadal skutecznie wysyłam wiadomość z powrotem do sklepu, bez względu na to, jak perfumuję świnię. Oczywiście akcja przechodzi teraz przez kilka warstw pośrednich (twórca akcji, dyspozytor), zanim dotrze do sklepu, ale jeśli czegoś nie brakuje, to komponentem, który wysyła to działanie dla wszystkich praktycznych zastosowań, jest aktualizowanie tego, co sklepy nasłuchują. zabij wiadomość.

Czego tu mi brakuje?

Znów wiem, że w Stack Overflow nie możemy zadać zbyt ogólnego pytania, więc chcę zachować to bardzo szczegółowe. Dwa fragmenty kodu, które mają różną składnię, wydają się być semantyczne (z wyjątkiem możliwości nadawania do wielu sklepów) dokładnie tak samo.

I znowu, jeśli jedynym powodem jest to, że umożliwia rozgłaszanie i umożliwia pojedynczy punkt przepływu dla celów debugowania, nie przeszkadza mi to, ale chciałbym wiedzieć, czy jest coś innego na temat strumienia/dyspozytora brakujący?

Answer 1

Główne cechy architektury flux stylu są w przybliżeniu następujące:

1. sklep jest jedynym źródłem prawdy o stanie aplikacji
2. tylko działania mogą wywołać mutację sklepu stanu
3. Stan sklepu nie powinien być bezpośrednio zmutowany, tzn. poprzez przypisywanie wartości obiektów, ale poprzez tworzenie nowych obiektów poprzez klonowanie/destrukturyzację:

Podobnie jak dieta, przy użyciu jest typ architektury naprawdę nie działa, jeśli poślizgniesz się i wracasz na stare sposoby z przerwami.

Powracanie do przykładu. Korzyścią z korzystania z tej akcji nie są aspekty rozgłaszania lub rejestrowania, ale po prostu fakt, że klasa People powinna móc pobierać dane ze sklepu i wyrażać swoje pragnienia zmutowania stanu wspomnianego sklepu za pomocą działań.Wyobraźmy sobie na przykład, że Elves chce śpiewać do ogra, a tym samym są zainteresowani, aby wiedzieć, że wspomniany wilkołak wciąż żyje. W tym samym czasie People chce być grzeczny i nie chce zabijać ogra podczas serenad. Korzyści z architekturą w stylu flux są jasne:

class People { 
    kill(creature) { 
    if (creatureStore.getSerenadedCreature() !== creature) 
     store.dispatch({ type: 'KILL', payload: { target: creature } }) 
    return `The ${creature} is being serenaded by those damn elves, let's wait until they've finished.` 
    } 
} 

class Elves { 
    singTo(creature) { 
    if (!creatureStore.getCreatures().includes(creature)) 
     return store.dispatch({ type: 'SING_TO', payload: { target: creature } }) 
    return `Oh no, the ${creature} has been killed... I guess there will be no serenading tonight..` 
    } 
} 

Jeśli klasa People było zawinąć do sklepu, którą trzeba klasę Elves owinąć tym samym sklepie, a także, tworząc dwa miejsca, gdzie ten sam stan zostałby zmutowany w taki czy inny sposób. Teraz wyobraź sobie, że gdyby było 10 innych klas, które potrzebują dostępu do tego sklepu i chcesz go zmienić: dodanie tych nowych funkcji staje się problemem, ponieważ wszystkie te klasy są teraz na łasce innych klas, które mutują stan od spodu, zmuszając cię do tego. do obsługi tonu przypadków skrajnych, nawet nie związanych z logiką biznesową tych klas.

Przy architekturze stylu strumienia wszystkie te klasy będą pobierać dane tylko z creatureStore i wywoływać akcje w oparciu o ten stan. Magazyn obsługuje uzgadnianie różnych działań ze stanem, aby wszyscy jego subskrybenci mieli właściwe dane w odpowiednim czasie.

Korzyści z tego wzoru mogą nie być widoczne, gdy masz tylko kilka sklepów, które są konsumowane przez jedną lub dwie jednostki. Gdy masz dziesiątki (lub setki) sklepów z dziesiątkami (lub setkami) składników zużywających dane z kilku sklepów, ta architektura pozwala zaoszczędzić czas i pieniądze, ułatwiając tworzenie nowych funkcji bez naruszania istniejących.

Mam nadzieję, że ta ściana-o-tekst pomogła wyjaśnić!

Answer 2

To, czego nie widzę, to jak umieszczanie działań w postaci obiektów JSON, nagle wymusza lub pomaga w "jednokierunkowym" przepływie komunikacji, co czytam wszędzie, jest wielką zaletą działania i strumienia. Wygląda na to, że nadal skutecznie wysyłam wiadomość z powrotem do sklepu, bez względu na to, jak perfumuję świnię. Oczywiście akcja przechodzi teraz przez kilka warstw pośrednich (twórca akcji, dyspozytor), zanim dotrze do sklepu, ale jeśli czegoś nie brakuje, to komponentem, który wysyła to działanie dla wszystkich praktycznych zastosowań, jest aktualizowanie tego, co sklepy nasłuchują. zabij wiadomość. Czego mi tu brakuje?

Facebook Flux skorzystał z pomysłów z systemów GUI sterowanych zdarzeniami. Tam nawet jeśli poruszasz myszą, otrzymujesz wiadomości. Nazywało się to wówczas pętlą komunikatów, a teraz mamy wysyłane akcje.

Ponadto mamy listę subskrybentów w sklepach.

To naprawdę ta sama zasada w Redux, gdzie masz jeden sklep, podczas gdy w Flux możesz mieć wiele sklepów.

Teraz mało matematyki. Mając 2 komponenty A i B musisz mieć tylko kilka możliwych łańcuchów aktualizacji Aktualizacje A i B aktualizacji B lub B (nie włączając w to aktualizacji z zewnątrz aplikacji). Jest to możliwy przypadek.

z zaledwie trzech komponentów mamy o wiele więcej możliwych łańcuchów.

I jeszcze więcej składników robi się skomplikowana.Aby więc tłumić wykładniczą złożoność możliwych interakcji z komponentami, mamy ten wzór Flux, który w niczym więcej niż IDispatch, IObservable, jeśli pracowałeś z tymi interfejsami z innych języków programowania. Jednym byłoby opluwanie akcji, a drugie wejście w łańcuch słuchacza, który istnieje w sklepie.

Przy pomocy tego wzoru kod React będzie zorganizowany w inny sposób niż w przypadku podejścia React. Nie będziesz już musiał używać stanu React.Component. Zamiast tego użyjesz Sklepów, które będą utrzymywać stan aplikacji.

Twój komponent może pokazywać tylko chęć zmutowania stanu aplikacji przez wysłanie akcji. Na przykład: onClick może wywołać akcję, aby zwiększyć licznik. Akcje są obiektami o właściwości type:, która jest zwykle ciągiem znaków i zwykle dużymi literami, ale obiekt akcji może mieć wiele innych rekwizytów, takich jak identyfikator, wartość, ...

Ponieważ komponenty są odpowiedzialne za renderowanie na stanie aplikacji musimy jakoś dostarczyć im stan aplikacji . Może być przez props = store.getState() lub możemy użyć context. Ale sprawdź także this.

Wreszcie, nie jest nawet zabronione, że składnik wykorzystuje stan wewnętrzny (this.state) w przypadku, gdy nie ma to wpływu na aplikację. Powinieneś rozpoznać te przypadki.