ng-redux - warto ?

Czesc robie refactor inteligentnego widgeta, z racji tego ze ma dostac coraz wiecej funkcjonalnosci przeniesionych z backendu na front trzeba go wciaz ulepszac a architektura widgetu tak srednio wyglada dlatego trzeba pozmieniac kilka rzeczy (prawie wszystko), idealne wrecz zadanie dla reacta, ale w tym wypadku odpada ze wzgledu na zbyt duzy mix technologiczny, dlatego pomyslalem o menadzerze stanu redux (ng-redux) dla wersji angularowej, poniewaz state'y beda zachowywac sie przewidywalnie, a nie tak jak teraz, ze child component zmienia state'y, a pozniej parent, ale jeszcze pozniej gdzies event sobie to zmienil i dopisujac nowa logike w sumie nie wiadomo gdzie to wpisac zeby sie nie wyje**o :D

Warto uzyc wzorca redux z angularem, czy po prostu napisac to w czystym angularze zachowujac idee reduxa ?

Nigdy nie stosowałem menedżera stanu w angularze, ale idea tak mi się podoba, że chętnie bym spróbował. Inni stosują z powodzeniem, więc myślę, że Ty też dasz rady (a potem pochwalisz się na forum jak poszło :D)

Wlasnie juz zabralem sie za przerabianie na ng-redux, ogolnie mialem czesc implementacji w komponentach i przyznam szczerze, ze troche mnie to gubi, kiedy, co jak, bo nie mamy scisle powiedziane jak ma wygladac przeplyw danych, raz z gory na dol, raz z dolu do gory, szczegolnie jak ktos wejdzie do projektu nowy, to bedzie mogl sie zastanawiac, jak to zrobic i gdzie co sie zmienia, z ktorego komponentu, moze to troche wprowadzic w blad i zamaskowac niektore rzeczy, wiec jak na razie mi sie podoba (pisze od tej godziny co napisalem posta :D)

Juz wyglada lepiej, co dopiero pozniej, jeszcze jak sobie pomysle ze testy do tego beda latwiejsze to juz w ogole bajka. Apka ma sporo logiki, wiec w tym przeznaczniu ma to sens chyba.

• Tzn. komponenty tak czy inaczej mam, ale po prostu na zasadzie (komponenty|serwisy) teraz mamy (komponenty|serwisy|ng-redux), serwis bardziej do wyznaczenia "when I can do this"