Luke J. Li

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

Moje Feedbacks coraz bardziej zaczyna przypominać Redux Saga. Nawet generatory już są. To trochę jakby takie coś podobnego do Redux Sagi, tylko bardziej funkcyjne i mocniej zintegrowane ze store'm. Można z reducerów zwracać efekty, one się rozwiązują i wartość idzie z powrotem do store'a. Jeszcze dokumentację zacząłem robić  https://github.com/hex13/feedbacks/blob/master/docs/api.md , ale wciąż jest niepełna. Chociaż jak chcecie zobaczyć jak to wygląda w praktyce to tu jest przykład:  https://github.com/hex13/feedbacks/blob/master/examples/calendar/src/store.js . Anyway, lepiej się tego już dzisiaj zaczynajcie uczyć, to za rok będziecie mogli powiedzieć na rozmowie, że macie już rok doświadczenia w Feedbacks. A myślę, że to może być hit na miarę Sagi albo i samego Reduxa. Taki game changer (dlaczego tak myślę? No po prostu o ile wciąż Feedbacks jest biblioteką młodą i nie wszystko w niej jest, to już widzę, że pozwala to drastyczne zmniejszenie ilości kodu związanego z Redu

W poprzedniej notce zastanawiałem się, czy nie wywalić możliwości zwracania obserwabli z reducerów i zastąpić je obiektami "efektów", jednak po przemyślaniu uznałem, że zostaje to i to. Mimo wszystko zwracanie obserwabli jest to killer-feature i może przypaść do gustu wielu osobom, nawet jeśli będzie miał pewne trade-offy i nawet jeśli sam będę ostrożny w jego używaniu. A i tak kod do tego ficzera jest już napisany i nie mogę go skasować (ponieważ kod rozwiązujący promisy czy obserwable potrzebny mi jest w innych miejscach, w których coś takiego robię), mógłbym jedynie sztucznie zrobić blokadę na zwracanie tego typu rzeczy z reducera, ale byłoby to bezcelowe. Pisałem, że nie będzie to skalowalne, ale tak w zasadzie to zależy od tego, kto będzie to pisał. Myślę, że jest możliwe napisanie czegoś większego na obserwablach tak, żeby to miało ręce i nogi w większej apce. W zasadzie po części w ogóle zacząłem robić tę libkę. Bo wg mnie obserwable są fajnym konceptem, ale brakuje

Zastanawiam się, czy nie wywalić flagowej opcji z mojej biblioteki. A mianowicie fakt, że reducer może zwracać obserwable i opakowane w funkcję promisy. Czyli teraz da się tak zrobić w Feedbacks : function reducer(state, action) { return () => Promise.resolve(123); } albo: function reducer(state, action) { return Rx.interval(1000); } Dlaczego chcę to wywalić? No bo załóżmy, że moja biblioteka będzie używana w dużych projektach. Wtedy takie machinacje obserwablami czy zwracanie asynchronicznych funkcji bezpośrednio z reducerów mogłoby sprawić, że projekt stałby się trudniejszy w debugowaniu albo trudne byłoby robienie jakichś mocnych zmian w implementacji (ponieważ wszystko w środku byłoby sprzężone z tymi obserwablami). Wpadłem na pomysł w jaki sposób mógłbym w bardziej elegancki sposób obsługiwać efekty uboczne. Tzn. dalej reducer zwracałby efekt uboczny, tylko, że nie wprost obserwable/asynchroniczne funkcje, a raczej obiekt z parametrami efektu np. {type: