Jaka jest rzeczywista różnica między reduxem a maszyną stanu (np. Xstate)?

Pracuję nad zbadaniem jednej aplikacji front-end o średniej złożoności. W tej chwili jest napisany w czystym javascript, zawiera wiele różnych komunikatów opartych na zdarzeniach, łączących kilka głównych części tej aplikacji.

Zdecydowaliśmy, że musimy zaimplementować jakiś kontener stanu dla tej aplikacji w zakresie dalszej refaktoryzacji. Wcześniej miałem pewne doświadczenie ze sklepem Redux i ngrx (który faktycznie kieruje się tymi samymi zasadami).

Redux jest dla nas opcją, ale jeden z programistów zaproponował użycie biblioteki opartej na maszynach stanowych, w szczególności biblioteki xstate .

Nigdy nie pracowałem z xstate, więc wydało mi się to interesujące i zacząłem czytać dokumentację i przyglądać się różnym przykładom. Wyglądał obiecująco i potężnie, ale w pewnym momencie zrozumiałem, że nie widzę żadnej znaczącej różnicy między nim a reduxem.

Spędziłem godziny, próbując znaleźć odpowiedź lub jakąkolwiek inną informację porównującą xstate i redux. Nie mogę znaleźć żadnej jasnej informacji, z wyjątkiem niektórych artykułów takich jak „dostać od Redux do machiny państwowej” , lub linki do bibliotek koncentruje się na wykorzystaniu Redux i xstate razem (dość dziwne).

Jeśli ktoś może opisać różnicę lub powiedzieć, kiedy deweloperzy powinni wybrać xstate - zapraszam.

Stworzyłem XState, ale nie zamierzam ci mówić, czy użyć jednego nad drugim; to zależy od Twojego zespołu. Zamiast tego spróbuję podkreślić kilka kluczowych różnic.

• Redux jest zasadniczo kontenerem stanu, w którym zdarzenia (zwane akcjami w Redux) są wysyłane do reduktora, który aktualizuje stan.
• XState jest również kontenerem stanu, ale oddziela stan skończony (np. "loading", "success") Od „stanu nieskończonego” lub kontekstu (np items: [...].).
• Redux nie dyktuje, jak definiujesz swoje reduktory. Są to zwykłe funkcje, które zwracają następny stan, biorąc pod uwagę bieżący stan i zdarzenie (akcję).
• XState to „reduktor z regułami” - definiujesz legalne przejścia między stanami skończonymi na skutek zdarzeń, a także jakie akcje mają być wykonywane w przejściu (lub przy wejściu / wyjściu ze stanu)
• Redux nie ma wbudowanego sposobu radzenia sobie z efektami ubocznymi. Istnieje wiele opcji społecznościowych, takich jak redukx-thunk, redux-saga itp.
• XState sprawia, że ​​akcje (efekty uboczne) są deklaratywne i jawne - są częścią Stateobiektu, który jest zwracany przy każdym przejściu (stan bieżący + zdarzenie).
• Redux nie ma obecnie sposobu na wizualizację przejść między stanami, ponieważ nie rozróżnia między stanem skończonym i nieskończonym.
• XState ma wizualizator: https://statecharts.github.io/xstate-viz, który jest wykonalny ze względu na deklaratywny charakter.
• Niejawna logika / zachowanie reprezentowane w reduktorach Redux nie mogą być serializowane deklaratywnie (np. W formacie JSON)
• Definicje maszyn XState, które reprezentują logikę / zachowanie, mogą być serializowane do JSON i odczytywane z JSON. To sprawia, że ​​zachowanie jest bardzo przenośne i konfigurowalne przez narzędzia zewnętrzne.
• Redux nie jest wyłącznie maszyną stanową.
• XState ściśle przestrzega specyfikacji W3C SCXML: https://www.w3.org/TR/scxml/
• Redux polega na programistach, aby ręcznie zapobiegać niemożliwym stanom.
• XState używa wykresów stanu do naturalnego definiowania granic obsługi zdarzeń, co zapobiega stanom niemożliwym i może być analizowane statycznie.
• Redux zachęca do korzystania z jednego, „globalnego” magazynu atomowego.
• XState zachęca do stosowania podejścia przypominającego model aktora, w którym może istnieć wiele hierarchicznych instancji stanów / „usług”, które komunikują się ze sobą.

W tym tygodniu dodam więcej kluczowych różnic do dokumentów.

Maszyna stanów nie mówi (wymusza), aby mieć jednokierunkowy przepływ danych. Nie ma to nic wspólnego z przepływem danych. Chodzi bardziej o ograniczanie zmian stanu i przejścia między stanami . Tak więc, generalnie tylko niektóre części aplikacji byłyby projektowane przy użyciu maszyn stanu, tylko i tylko wtedy, gdy trzeba ograniczyć / zabronić pewnych zmian stanu i interesują się przejścia.

Pamiętaj, że w przypadku automatów stanu, jeśli z jakiegoś powodu (zależność od zewnętrznego interfejsu API itp.) Jest szansa, że ​​aplikacja może zostać zablokowana w stanie, w którym nie może przejść do innego stanu z powodu ograniczeń, musisz to rozwiązać.

Ale jeśli interesuje Cię tylko sam stan ostatniej aplikacji, zamiast przejść między stanami , a ograniczenia stanu nie mają znaczenia, to lepiej nie używać automatu stanowego i bezpośrednio aktualizować sam stan ( nadal możesz zawijać stan w aktualizacji klasy Singleton poprzez Zajęcia Action ).

Z drugiej strony Redux to architektura jednokierunkowa . Architektury jednokierunkowe wymuszają jeden kierunek przepływu danych. W Redux zaczyna się od User->View->(Action)->Store->Reducer->(Middleware)->Store->(State)->View. Podobnie jak maszyny stanowe, możesz wywoływać efekty uboczne za pomocą oprogramowania pośredniego w Redux. Jeśli chcesz, możesz ograniczyć / zabronić przejścia między stanami. W odróżnieniu od maszyny stanowej , Redux wymusza jednokierunkowy przepływ danych, czysty ! funkcje reduktora, niezmienne obiekty stanu, pojedynczy obserwowalny stan aplikacji.