postępy mojej libki (tej, która będzie alternatywą dla Reduxa)

postępy mojej biblioteki Vistate są takie, że:

architektura

architektura jest już całkiem okej (co prawda musiałem pójść na pewne trade offy, ale jednak myślę, że ma to szansę być skalowalnym rozwiązaniem). Korzystam ze wzorca projektowego Entity-Component-System, który jest używany w grach, a ponieważ nowoczesna developerka JS przypomina trochę robienie gier, to doszedłem do wniosku, że to właściwie to samo. Przy czym ECS używam tylko do middleware'ów. Użytkownicy biblioteki nie muszą o tym nawet wiedzieć, oni mają po prostu modele.

A poza tym mimo wszystko dalej moje rozwiązanie jest dość reduxowe, czyli wywołujesz jakieś akcje, odpalają się funkcje, które "zmieniają stan" (tylko różnica jest taka, że o ile reducery w Redux zwracają stan końcowy, to ja działam na drobniejszym poziomie detali i funkcje nie zwracają stanu końcowego, tylko raczej mówią modelowi "co się powinno zmienić" i model to potem dopiero zmienia. Jest to inspirowane wzorcem SAM. Wg mnie to bardzo fajna sprawa, bo pozwala mi automatycznie wykrywać "co się dokładnie zmieniło", co pozwala choćby na pokazanie tego w dev toolsach:

wydajność

Dzisiaj zaimplementowałem blokadę odpalenia kilka apdejtów po kilku akcjach (tzn. nawet jak walniesz kilka akcji z rzędu, to odpali się tylko jeden apdejt, żeby nie spowalniać GUI apdejtami).

Dla kontrastu - taki Redux tego nie obsługuje out of the box (a jeden z moich głównych problemów z Reduxem było właśnie to, że po każdej akcji się triggerowały apdejty, co powodowało spadek wydajności i konieczność partyzantki typu shouldComponentUpdate). No i u mnie apdejty się odpalają tylko wtedy, gdy rzeczywiście po akcji nastąpiła mutacja (w Redux się odpalają nie zależnie czy jest mutacja czy nie). Czyli ma to szansę być bardziej wydajnym rozwiązaniem od Reduxa.

wygoda użytkowania

nad tym pracuję właśnie, generalnie w miarę prosto będzie się obsługiwać, chociaż będzie parę gotchas. Ale w każdej bibliotece są pewne rzeczy, które trzeba załapać (u mnie może być to różnica między modelem a encją - którą wprowadziłem. Co prawda użytkownik i tak będzie głównie z modelu korzystał (encja będzie stała za modelem, za scenami), ale jednak jest to pewnego rodzaju dziwność (może z niej zrezygnuję jeszcze - ale póki co to mi ładnie separuje high level interface od technicznych detali).

 jakość kodu

 ponieważ dokonuję dużego refaktoru to mam jeszcze dużo bajzlu w kodzie. Ale nie martwię się, bo mam pokrycie kodu testami między 90 a 100% więc po prostu refaktoruję to powoli i w końcu coś się krystalizuje.

stabilność biblioteki

ponieważ jeszcze prawie codziennie robię breaking changes, nie mogę powiedzieć, że api biblioteki jest stabilne. No ale myślę, że za jakiś czas się to ustatkuje.

dev toolsy

w trakcie robienia :) chociaż na razie w formie jedynie live demo, nie wrzuciłem kodu dev toolsów na Github jeszcze. Ale można się pobawić. hex13.github.io/demos/todo/

dokumentacja

jest tylko koncepcyjna: https://github.com/hex13/enter-ghost/tree/master/packages/vistate
natomiast w zasadzie nie ma za bardzo dokumentacji pod tytułem "jak tego używać" (poza małym kawałkiem przykładowego kodu), więc tym się jeszcze zajmę.

instalacja

jakbyście chcieli używać, to z Githuba, ponieważ nie aktualizuję NPM na bieżąco (ale w sumie nie jest to jeszcze w takim stanie "produkcyjnym". Jak uznam, że będzie się to nadawało na produkcję to apdejty na NPM się będą pojawiać regularnie).