W rzeczywistości badam wzór strumienia i jest coś, czego nie mogę zrozumieć, jeśli chodzi o sklepy .
Czym one dokładnie są?
Przeczytałem wiele artykułów i wydaje mi się, że dotyczy to domain.
Czy to oznacza, że jest to „abstrakcyjna” część związana z wywołaniami API lub backendowymi?
Nie jest to dla mnie zbyt jasne.
Edycja: Czy to może być to samo, co fabryka kątów? Pobieranie zdalnych danych, wykonywanie zadań biznesowych lub przechowywanie niektórych stanów aplikacji (na przykład bieżący użytkownik podłączony)?
Komentarze
- Link do tego, co dokładnie ' rozmowa byłaby pomocna. Czy masz na myśli ten " wzór strumienia "? fluxxor.com/what-is-flux.html
- facebook.github. io / flux / docs / overview.html # content
- Flux to nic innego jak wzorzec publikowania / subskrypcji z ograniczeniem, że wszystkie dane przechodzą najpierw przez dyspozytor. Gwarantuje, że dane nie cofają się (i nie powodują zamieszania). Na przykład " Sklep ", " Akcja " etc to tylko inny sposób na powiedzenie Składniki systemu i dane, które są przekazywane.
Odpowiedź
Ok, pozwól, że wyjaśnię Ci krok po kroku
1 Co to jest Flux?
- Wzorzec
- Scentralizowany dyspozytor
- Jednokierunkowe przepływy danych
- Element listy
Nie bez powodu nazywają to Flux.
Implementacje Flux
- Flux Facebooka
- Alt
- Reflux
- Flummox
- NuclearJS
- Fluxible
Czat z Flux
Reaguj : Hej Akcja, ktoś kliknął „Zapisz Cour se ”.
Akcja : Dzięki, zareaguj! Zarejestrowałem twórcę akcji u dyspozytora, więc dyspozytor powinien zająć się powiadomieniem wszystkich sklepów, które się tym przejmują.
Dyspozytor : Pozwól mi zobaczyć, komu zależy na zapisaniu kursu. Ach! Wygląda na to, że Sklep zarejestrował u mnie oddzwonienie, więc dam jej znać.
Sklep : Cześć dyspozytorze! Dziękuję za aktualizację! Zaktualizuję moje dane wysłanym przez Ciebie ładunkiem. Następnie wyemituję zdarzenie dla komponentów Reacta, które ich interesują.
React : Ooo! Błyszczące nowe dane ze sklepu! Zaktualizuję interfejs użytkownika, aby to odzwierciedlić!
Flux API
register (wywołanie zwrotne funkcji) – „Hej dyspozytorze, uruchom mnie, gdy coś się wydarzy. -Store ”
unregister (string id) -„ Hej dyspozytorze, przestań się martwić o tę akcję. -Store ”
waitFor (identyfikatory tablicy) -„ Najpierw zaktualizuj ten sklep. –Store ”
wysyłka (ładunek obiektu) -„ Hej dyspozytorze, powiedz sklepom o tej akcji . -Action ”
isDispatching () -„ Jestem zajęty wysyłaniem wywołań zwrotnych w tej chwili. ”
więc pytanie, które nasuwa się nam w głowie, brzmi:
Więc Flux jest modelem publikuj-subskrybuj?
Niezupełnie.
Różni się na dwa sposoby:
1. Każdy ładunek jest wysyłany do wszystkich zarejestrowanych wywołań zwrotnych.
2. Oddzwaniania mogą czekać na inne wywołania zwrotne
Podsumowanie
Flux to wzorzec dla jednokierunkowych przepływów danych Akcje hermetyzują zdarzenia Dispatcher to centralne centrum przechowujące wywołania zwrotne Sklepy przechowują stan aplikacji Wiele implementacji
Komentarze
- Mój pierwszy problem czy ten stan pozwala aplikacji na posiadanie różnych danych zdalnych jednostek API: – /
- co masz na myśli mówiąc, że stan pozwala? wszędzie tam, gdzie wywoływana jest zmiana emisji, wywołuje ona widok React View i ponownie wywołuje metodę zmiany stanu
- Przyznając, że buduję aplikację ze strumieniem. Mam do czynienia z API, a następnie zapisuję dane w moich sklepach. Co się stanie, jeśli użytkownicy zmodyfikują zdalne dane? Będę mieć różnicę między klientem a serwerem
- teraz, gdzie mogę znaleźć dlaczego. Jeśli wszyscy dyspozytorzy i sklep mają zamiar przekierować do widoku, to dlaczego ' t akcja aktualizuje widok bezpośrednio.dlaczego są pośrednicy
- @MuhammadUmer: Dispatcher jest jednym z aplikacji, a sklep jest oparty na komponencie w aplikacji, więc aby usunąć nadmiarowość, wprowadzono pośredników
Odpowiedź
Wyszukiwanie prostego przykładu ( https://github.com/facebook/flux/tree/master/examples/flux-todomvc/ ), „Magazyny zarządzają stanem aplikacji dla określonej domeny w aplikacji.” Oznacza to, że zawierają dane o stanie aspektu aplikacji i cały kod do jego zmiany. Za każdym razem, gdy pojawi się nowa aktualizacja z dyspozytora, wszystkie sklepy ją zobaczą, w odpowiedzi decydują, jak zaktualizować swoje dane, a następnie powiadamiają widoki, że dane uległy zmianie. W przykładach Sklepy zawierają takie rzeczy, jak „lista niewidocznych wątków” (gdzie Dyspozytor powiadamia ich o nadejściu nowej wiadomości lub przeczytaniu starej, a Widoki wyświetlają wątki wiadomości dla użytkownika) i „aktualny czas odtwarzania i stan. ”
Bardziej technicznie: są one pośrednią warstwą frameworka, która rejestruje wywołania zwrotne w Dispatcherze w celu otrzymywania aktualizacji, a następnie powiadamia Widoki o zmianie stanu danych. (Widoki mogą następnie wysyłać akcje z powrotem do Dyspozytora). Wdrażają abstrakcyjny interfejs, w którym każdy Sklep rejestruje wywołanie zwrotne u Dyspozytora i transmituje zdarzenia do Widoków, ale wydaje się, że każdy Sklep reprezentuje określoną domenę w konkretny sposób. (Czy istnieją kontrprzykłady?)
Odpowiedź
Magazyny to obszary kodu przechowujące stan aplikacji i złożoną logikę. Powodem ich jest to, że wiele widoków prawdopodobnie będzie używać tych samych danych, ale wyświetli je w inny sposób lub wyświetli niektóre, ale nie wszystkie dane dla określonej domeny. Na przykład użytkownik loguje się i otrzymuje jego imię, nazwisko, e-mail, zdjęcie, miejscowość, numer adresu, numer telefonu itp. Informacje te są wyświetlane w osobnych widokach. Zamiast powielać dane w widokach, możemy użyć jednego Sklepu o nazwie UserStore, który przechowuje dane dla użytkownika. Upraszcza to system, dając „jedno miejsce na dokonanie zmiany”, ilekroć logika lub przechowywane dane muszą zostać zmienione. Istnieje wiele innych powodów, dla których warto korzystać ze Sklepu, ale wydaje mi się, że jest to najbardziej oczywisty.