Scala sttp4 jsoniter wip

[Kamil-Lontkowski]

To nie jest niestety skończone, ale myśle że udało się rozwiązać na pewno kilka problemów a też nie wszystko ten codegen musi implementować.

Co zostało zrobione:

1. Bezpieczna serializacja form-params zgodna ze specyfikacją
2. obsługa Option[File]
3. Poprawne generowanie enumów (przynajmniej to co było oczywiste)
4. Podbicie wersji Sttp do RC1
5. Poprawa błędów kompilacji związanych z podbiciem (ResponseException oraz asFile)
6. Serializacja query params
7. Brak codeca dla klas z java.time
8. Konflikty nazw z None
9. Auth support
10. Serializacja cookies, path params oraz headers

Co zostało do zrobienia:

Blockery

1. formatIdentifier tak formatuję że często pojawiają się takie same case'y w enumach - tutaj jest to rozwiązane, formatIdentifier nadal psuję w niektórych przypadkach nazwy pól w modelach
2. multipart (tu są różnice między 3.0 i 3.1 i ciężko dość jak mają być serializowane parametry)
3. serializacja enumów w query oraz forms ( trzeba zobaczyć jak to gra z ewentualnymi codecami jsonitera) na enumach jest wykorzystywany codec jsnonitera

Reszta:

1. Nie generują się enumy dla modeli, które są tylko w params - jest po prostu string(nawet nie najgorszy case)
2. Jak jest wyłączony polimorfizm to w jednym miescu jest źle ustawiona flaga isEnum przez co ten enum się nie generuję
3. Myśle że można z niewielkim wysiłkiem dodać wsparcie dla cookies Done
4. Nadal są jakieś ustawienia związane z bibliotekami do time. Skoro Scala 3 jest na java 8+ to raczej powinniśmy używać java.time API a reszte wywalić
5. Nie jestem pewien czy jak api wspiera np. XML i json to czy json jest zawsze na pierwszym miejscu (tak zakłada szablon, pewnie trzeba się upewnić)
6. urlencoded wspiera teoretycznie możliwość serializacji co json (też np. w multipart)
7. Serializacja parametrów typu LocalDate lub OffsetDatetime - nie patrzyłem czy jest to prawidłowe
8. mulitpart pozwala na zdefiniowanie format dla pliku jak base64 - na razie tego nie wspieramy
9. Pytanie czy chcemy patrzeć na polimorfizm - allOf to zwykłe dziedziczenie, jeśli ta cała machina jest w stanie to przetłumaczyć na pełen model to nie ma problemu. oneOf to jest ADT, jsoniter wspiera takie coś, pytanie w jakim zakresie - czy musi być dyskriminator. anyOf to ogólnie działa w stylu próbuj deserializować wymienione modele póki się nie uda - nie wiem jak do tego podejść

Mogę dość prosto dodać możliwość serializacji parametrów za pomocą FromSerializable za pomocą typeclassy - jeśli taka typeclassa będzie w scope to nadpisze domyślną próbe serializacji - to by pozwoliło ogarnąć te wszystkie dziwne przypadki ze stripe Dodałem typeclassy dla serializacji tych parametrów. Wystarczy że będzie w scopie danego endpointa

Ogólnie wydaję mi się że stripe wymaga na pewno spojrzenia co tam jest dokładnie. Np. są tam chyba rekursywne typy, przez co jsoniter nigdy nie jest w stanie stworzyć codeców - kręci się aż skończy się pamięć.

Stan na 05706ee kompiluję bez problemu:

• mattermost
• petstore (v2 oraz v3)
• spotify.

W kubeapi jest dziwny problem gdzie jeden parametr trafia jako form param do danych szablony zamiast pathParam - tu chyba nic nie da się zrobić, jakiś błąd w codegen.

Github nie kompiluję się ze względu na dwa brakujące enumy oraz błąd w nazwach pól w modelu (dokładnie są takie pola jak "+1" oraz "-1").

W Stripe wydaję się że głównie błąd w codecach - rekursywne typy w jsoniter oraz brak serializacji przypadków niezgodnych ze standardem.

[lbialy]

ciekawe z tym jsoniterem, on ma wsparcie dla rekursywnych typów, trzeba je walczyć w konfiguracji tylko

[lbialy]

cholera, najlepsze libki zblokowane

[Kamil-Lontkowski]

Kubeapi i github po ręcznych zmianach się kompilują ale github może coś nie działać, bo tam jest używany polimorfizm a na razie jest to explicit wyłączone