Co poszło źle z Redux Sagą?

Więc tak. O ile Redux Saga ma fajny model efektów  to jednak pewne rzeczy poszły w Redux Saga i jej ekosystemie nie do końca dobrze.

Najpierw o tym co jest dobre i fajne. Czyli sama zasada działania: piszesz generator, który zawiera jakąś tam logikę interakcji, a żeby odpalić efekty uboczne to zwracasz sterowanie (przez yield) do interpretera efektów, który wykonuje efekt i zwraca sterowanie z powrotem do generatora. Tym sposobem izolujesz logikę od efektów ubocznych. Bardzo na propsie.

Ale jednak...

brak integracji ze storem 

Czyli coś, co w Feedbacks jest, w Redux Saga nie. W Feedbacks generatory działają w kontekście jakiejś właściwości w store, w Redux Saga działają niejako poza storem, co sprawia, że żeby coś zmienić w storze trzeba wysłać akcję - więc zmieniasz 5 rzeczy, to tworzysz 5 dodatkowych akcji i 5 razy zmieniasz reducery. Masakra. Czyli w zasadzie Redux Saga wcale nie likwiduje reduksowego "boilerplate'u", a tylko dokłada do niego kolejną cegiełkę.

dziwne nazewnictwo 

Dlaczego "take" albo "put"? Rozumiem, że niby "weź akcje" albo "połóż akcje", ale i tak dziwnie. Czemu nie zamiast "take" zrobić być "waitFor" albo "on"? A zamiast "put" np. "dispatch"? No i ogólnie mam wrażenie, że słownictwo w Redux Saga jest takie, żeby brzmiało "mądrze", a niekoniecznie było intuicyjne.

testowanie 

Czasem widzę, jak ludzie testują sagi w ten sposób, że odpalają je po kawałku (jak w sadze jest 5 yieldów to odpalą 5 razy) i patrzą co im ta saga zwróciła, karmią ją mockami itp. Wszystko fajnie, "testowalne", tylko co to testuje tak naprawdę? Przecież to nie testuje zachowania, a jedynie to, czy w sadze po odpowiednim yieldzie pojawia się kolejny yield. To jak badanie procentu cukru w cukrze.

Idąc tą drogą zbliżamy się do antywzorca, w którym testy odzwierciedlają 1:1 implementację (a co jeśli będziemy chcieli zmienić implementację? Będziemy musieli zmienić testy. Niedobrze). 

Wg mnie powinny być jakieś dedykowane narzędzia do testowania całych sag, jakiś specjalny silnik, który by je odpalał i który to silnik możnaby karmić kolejnymi eventami (np. wysłaniem akcji) i badać zachowanie całej sagi naraz. Albo wręcz po prostu całego systemu (czyli testy jak się cały store zachowuje, a nie jedna akcja). Testy "jednostkowe" są przereklamowane.

call 

Zawsze jak patrzę na call z sagi to zastanawia mnie czemu tak:

yield call(fetch, "example.json")

A nie tak

yield () => fetch("example.json")

Albo tak:

yield call("fetch", "example.json")

Drugie rozwiązanie zdaje się być najwygodniejsze dla użytkownika - yieldujesz funkcję bez zabawy w call. Prosto do celu niczym strzała () => Trzecie rozwiązanie wydaje się być najbardziej elastyczne - nie yieldujesz funkcji bezpośrednio ale tylko "typ funkcji"w stringu (tutaj: "fetch") czyli sygnalizujesz, że chcesz zrobić "fetch", a od silnika zależy co z tym zrobi. Może to będzie fetch z przeglądarkowego API, może to będzie Axios, cokolwiek, co będzie podczepione pod silnik Sagi. Nawet jakaś fejkowa implementacja.

Natomiast pierwsze rozwiązanie ani nie jest zwięzłe (bo dodatkowe pisanie call i podawanie argumentów) ani nie ma zalet rozwiązania trzeciego (czyli nie ma możliwości oddzielenia intencji ("fetch") od implementacji i generatory są sprzężone z implementacją.

Czyli po co to zrobili?

ogólna opinia ludzi

Ludzie i tak mają ostateczny głos na temat tego, czy dana biblioteka będzie używana i w jakich sytuacjach). W przypadku Redux Saga spotykam się z opiniami, że jest to złożona biblioteka i że do prostszych rzeczy lepiej użyć Thunka.

Czyli patrzcie - coś, co zasadę działania ma prostą jak drut (jak się zrozumie jak działają generatory ES6) i coś, co pozwala teoretycznie na bardziej czytelne programowanie (mimo wszystko) zostało i tak niezrozumiane oraz potraktowane jako coś do zaawansowanych rzeczy.

Czyli coś poszło nie tak.

(dobra, co do Thunka to sama implementacja jest mega prosta, kilkanaście lini kodu i nie lekceważyłbym Thunka jako podstawowego middleware do prostych rzeczy, jak ktoś nie chce używać niczego więcej. Tylko, że prostota implementacji samej biblioteki potem się mści na tym, że kod projektu jest bardziej złożony. Thunki mają paradoksalnie tendencję do rozrastania się i bycia nieczytelnymi)