Zastrzeżenie: Jestem jednym z autorów książki redux-obserwowalnej, więc trudno mi być w 100% bezstronnym.
Obecnie nie podajemy żadnego powodu, dla którego obserwowalna redukcja jest lepsza niż saga redux, ponieważ ... tak nie jest. 😆
tl; dr są wady i zalety obu. Dla wielu jeden jest bardziej intuicyjny niż drugi, ale oba są trudne do nauczenia się na różne sposoby, jeśli nie znasz RxJS (obserwowalny redux) lub generatorów / „efektów jako danych” (saga redux).
Rozwiązują ten sam problem w bardzo podobny sposób, ale mają pewne fundamentalne różnice, które stają się naprawdę widoczne dopiero, gdy użyjesz ich wystarczająco dużo.
obserwowalny redux odkłada prawie wszystko na idiomatyczny RxJS. Więc jeśli masz wiedzę RxJS (lub ją zdobywasz), uczenie się i używanie redux-obserwowalne jest super naturalne. Oznacza to również, że tę wiedzę można przenieść na inne cele niż redukx. Jeśli zdecydujesz się przejść na MobX, jeśli zdecydujesz się przejść na Angular2, jeśli zdecydujesz się przejść na jakąś przyszłą popularność X, są bardzo duże szanse, że RxJS może ci pomóc. Dzieje się tak, ponieważ RxJS jest ogólną biblioteką asynchroniczną i pod wieloma względami przypomina sam język programowania - cały paradygmat „programowania reaktywnego”. RxJS istniał od 2012 roku i zaczynał jako port Rx.NET („porty” są dostępne w prawie każdym głównym języku, jest to przydatne ).
redux-saga zapewnia swoje operatory oparte na czasie, więc chociaż wiedza, którą zdobędziesz na temat generatorów i radzenia sobie z efektami ubocznymi w tym stylu menedżera procesów, jest przenoszalna, rzeczywiste operatory i użycie nie jest używane w żadnej innej dużej bibliotece. To trochę niefortunne, ale z pewnością nie powinno samo w sobie przełamać umowy.
Używa również "efektów jako danych" ( opisanych tutaj ), co może być trudne na początku, ale oznacza to, że kod sagi redux w rzeczywistości sam nie wykonuje efektów ubocznych. Zamiast tego funkcje pomocnicze, których używasz, tworzą obiekty, które są jak zadania, które reprezentują zamiar wywołania efektu ubocznego, a następnie wewnętrzna biblioteka wykonuje go za Ciebie. To sprawia, że testowanie jest niezwykle łatwe, bez potrzeby kpiny i jest bardzo atrakcyjne dla niektórych osób. Jednak osobiście odkryłem, że oznacza to, że twoje testy jednostkowe ponownie zaimplementują większość logiki twojej sagi - co sprawia, że te testy nie są zbyt przydatne IMO (ta opinia nie jest podzielana przez wszystkich)
Ludzie często pytają, dlaczego nie robimy czegoś takiego z obserwowalnymi reduksami: według mnie jest to zasadniczo niekompatybilne z normalnym idiomatycznym Rx. W Rx używamy takich operatorów, .debounceTime()które hermetyzują logikę wymaganą do odbicia, ale to oznacza, że jeśli chcieliśmy stworzyć wersję, która nie wykonuje odbicia, a zamiast tego emituje obiekty zadań z zamiarem, straciłeś teraz moc Rx, ponieważ nie można już po prostu łączyć operatorów, ponieważ operowaliby na tym obiekcie zadania, a nie na rzeczywistym wyniku operacji. Naprawdę trudno to elegancko wyjaśnić. Znowu wymaga głębokiego zrozumienia Rx, aby zrozumieć niezgodność podejść. Jeśli naprawdę chcesz czegoś takiego, sprawdź cykle redukcyjnektóry korzysta z cycle.js i głównie ma te cele. Wydaje mi się, że wymaga to zbyt wiele ceremonii jak na mój gust, ale zachęcam do zakręcenia, jeśli Cię to interesuje.
Jak wspomniał ThorbenA, nie cofam się przed przyznaniem, że Redux-saga jest obecnie (13.10.16) wyraźnym liderem w złożonym zarządzaniu skutkami ubocznymi reduxu. Został uruchomiony wcześniej i ma bardziej solidną społeczność. Tak więc używanie de facto standardu w stosunku do nowego dzieciaka z bloku jest bardzo atrakcyjne. Myślę, że można bezpiecznie powiedzieć, że jeśli używasz któregokolwiek z nich bez wcześniejszej wiedzy, możesz się trochę pomylić. Obaj używamy dość zaawansowanych koncepcji, które, gdy już się „dostaniesz”, znacznie ułatwiają zarządzanie złożonymi skutkami ubocznymi, ale do tego czasu wielu się potyka.
Najważniejszą radą, jakiej mogę udzielić, jest to, aby nie sprowadzać żadnej z tych bibliotek, zanim będziesz ich potrzebować. Jeśli wykonujesz tylko proste wywołania Ajax, prawdopodobnie ich nie potrzebujesz. redux-thunk jest głupi, łatwy do nauczenia i zapewnia wystarczającą ilość podstaw - ale im bardziej złożona asynchronizacja, tym trudniejsza (lub nawet niemożliwa) staje się dla redux-thunk. Ale w przypadku sagi obserwowalnej przez reduksa pod wieloma względami świeci ona najbardziej, im bardziej złożona jest asynchronizacja. Jest też wiele zalet używania Redux-thunk z jednym z pozostałych (redukx-obserowalne / saga) w tym samym projekcie! redux-thunk dla zwykłych prostych rzeczy, a następnie używając tylko redux-observable / saga do złożonych rzeczy. To świetny sposób na utrzymanie produktywności, więc nie walczysz z obserwowalnymi / sagami reduxu o rzeczy, które byłyby trywialne w przypadku Redux-thunk.