Luke J. Li

Dlaczego te moje Feedbacks to jedynie dodatek do Reduxa, a nie cała oddzielna biblioteka? No cóż. Jest kilka powodów. 1. Ekosystem . możliwość korzystania z całego ekosystemu Reduxa, innych dodatków itp. Nie będę musiał tworzyć całego ekosystemu od nowa. Tworząc bibliotekę od zera musiałbym nawet dev toolsy stworzyć do niej (chociaż może i tak stworzę, albo zmodyfikuję Redux Dev Toolsy, bo mają za mało ficzerów). Tak samo musiałbym tworzyć wiązania do Reacta i sposoby na integrację z wieloma innymi bibliotekami. A w Redux już są tego typu rzeczy. 2. popularność Reduxa . No sorry, ale już powstało ileś alternatyw, a mimo to nikt się nie przebił poza Reduxa, nie wiadomo jak bardzo fajne by było. Taki Mobx ma o wiele więcej ficzerów od Reduxa, a i tak wszyscy tego Reduxa chcą używać (nie jestem fanem Mobx, bo dla mnie tam się zbyt dużo ukrytej magii dzieje. Jednak wolę rozwiązania explicite, a w Mobx masę rzeczy jest implicite. Nie dla mnie. Ale mimo wszystko ficzerami Mobx gniecie...

Piszę właśnie swoją nową bibliotekę. Częściowo jest to kolejna próba naprawienia Reduxa, jednak od poprzednich będzie się różnić tym, że zamiast tworzyć "alternatywę do Reduxa", to postanowiłem jednak napisać do tego Reduxa zwykły dodatek (middleware + automatyczne tworzenie reducera). Biblioteka się nazywa Feedbacks (jak doczytacie dalej, to będzie jasne, skąd ta nazwa). I jest już dostępna na Githubie oraz na npm . A więc Feedbacks zamienia Reduxa w reaktywny silnik stanu , która sam aktualizuje sobie stan na podstawie tego, co zwrócą: - obserwable (celuję głównie w Rx.js, ale rozważam wsparcie dla innych, podobnych bibliotek) - promisy - reducery indywidualne dla każdego "pola" (właściwości) w stanie (trochę jak w combineReducers, ale lepiej, bo dodałem do tego bardziej zaawansowany pattern matching, np. można robić coś takiego: match({type: 'foo', payload: {name: 'bar'}}, (value, action) => 42} i dopasowywać akcję pod kątem tego, co m...