Myślę, że najbezpieczniejszą drogą będzie, abyśmy wszędzie korzystali z natywnych promisów, a z Bluebirda korzystali tylko do koordynacji asynchroniczności, np. Bluebird.reduce, Bluebird.props, etc. Zamiast Bluebird.all możemy korzystać z Promise.all 
1 Like
Mam pytanie, czasem stosujemy coś takiego, że jeżeli mamy nieprawidłowy action_name to rzucamy DeveloperError - sensowne w czystym JSie. Ale przyszedł mi do głowy pomysł, żeby rozbić typ ActionName na podtypy ShowActionName, CreateActionName itd. i w poszczególnych subjectach zamiast rzucać wyjątek gdy action_name nie jest obsługiwany, to wystawić to w deklaracji funkcji performAction(context: Context, action_name: ShowActionName,params: any). Wydaje się to ok?
Musimy pamiętać o tym, że type safety to jedno, ale wciąż musimy sprawdzać nazwę akcji w trakcie runtime’u. Więc ten wyjątek musimy rzucać, nawet jeżeli teoretycznie to nie jest możliwe z punktu widzenia typów. Wszak można będzie korzystać z Sealiousa za pomocą zwykłego JS-a, który nie rzuci błędu, gdy typy nie będą się zgadzały
A racja, bo do tego będzie dostęp z zewnątrz. A w sumie jakie mamy podejście do bibliotek, które oferują tzw. runtime types? Mam na myśli io-ts, tutaj krótki artykuł
O, myślałem kiedyś o czymś takim! Ale jeszcze nigdy nie korzystałem. Myślę, że warto pomyśleć o io-ts jak już będziemy mieli ogarniętego typescripta w Sealiousie 
Ustaliliśmy z @kuba-orlik, że jeśli ktoś napotka promisifyowanie method z fs, to można śmiało to przepisać na fs Promises API
1 Like
Pusznąłem kolejne zmiany. Zeszliśmy już do 1316 błędów (z ponad 2k 
) Będę kontynuował prace nad field-typesami.
Kontynuuję prace nad field-typesami. Zeszło już do 1224 errorów.
Przysiedziałem dzisiaj jeszcze trochę. Mamy już tylko trzycyfrową ilość błędów: 973
2 Likes
U mnie ostatnio intensywnie w innych sprawach i niespecjalnie siedziałem nad tym, ale kontynuuję temat subjectów
1 Like
Skończyłem dodawać typy do field-types’ów, ilość błędów aktualnie: 905.
Następnie będę siadał do graph.js
Usiądę na szybko do with-test-app
Done, ilość błędów zeszła do 858
Teraz siadam do time-units.js i secure-hasher.js
Done, ilość błędów: 836. Siadam do test_utils
Done, ilość błędów: 819. Siadam do utils
Done, ilość błędów: 774, siadam do access-strategies
Done, ilość błędów: 766, siadam do special-filters
Done, ilość błędów: 750, siadam do config-manager
Done, ilość błędów: 737, siadam do file-manager
Done. Ilość błędów: 731. Siadam do hookable.subtest.ts
Done. Ilość blędów: 692. Siadam do request-multiple-items.subtest
Done. Ilość błędów: 676. Siadam do run-action-curry
Done. Ilość błędów : 666.
Używam od teraz tego skryptu, aby znaleźć najbardziej kłopotliwe pliki:
npm run build | grep -o -e '^[^(]*\.[jt]s' | sort | uniq -c | sort -n
Siadam do graph.test.js
Done. Ilość błędów: 609. Zabieram się za datastore
Done. Ilość błędów: 569. Zabieram się za query_and
Done. Ilość błędów: 562. Zabieram się za query.test
Done. Ilość błędów: 532. Zabieram się za query-step.ts
Wrzuciłem subjecty. Liczba błędów: 202. Wszystkiego nie udało mi się tam zrobić, ale jest dużo, dużo lepiej.
Dodam, że mam problem z 2 metodami z Collection.
encodeFieldValues -> wydaje mi się, że argument old_body powinien być opcjonalny (gdy tworzymy).
validateFieldValues -> argument field_type_name jest w ogóle źle nazwany - na alphie jest przekazywany tutaj this.name czyli nazwa kolekcji. Może po prostu wylecieć.
Mogę to naprostować? Póki co przyjrzę się http/routes
1 Like
zgadzam się 
to niech wyleci 
Potypowałem trochę więcej. Zeszło do 156 errorów
Naprawianie testów idzie do przodu
1 Like
Piekło zamarzło i powstała dokumentacja Sealiousa:
https://sealious.sealcode.org/docs/
Póki co jest do w postaci technicznego reference. Następnym krokiem będzie przygotowanie kilku poradników i use-case’ów.
1 Like