Typescript w Sealiousie!

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 :slight_smile:

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 :muscle:

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 :sweat_smile:) 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 :muscle:

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

:tada:

zgadzam się :white_check_mark:

to niech wyleci :white_check_mark: :smiley:

Potypowałem trochę więcej. Zeszło do 156 errorów

Ok, typescript zrobiony :muscle:

Teraz czas na testowanie

1 Like

Naprawianie testów idzie do przodu :muscle:

image

1 Like

:rotating_light::rotating_light::rotating_light::rotating_light: wszystkie testy przechodzą :tada:

2 Likes

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