Frontend Thursday vol. 69 – Blitz.js, Ember 4.0, typowane formularze dla Angulara

1. Pivot Blitz.js

Blitz.js to framework oparty o Reacta przy pomocy którego tworzyć można fullstackowe aplikacje. Dzięki zamknięciu wewnątrz jednego narzędzia zarówno frontendu jak i backendu, całość tworzy mocno monolityczną architekturę. To z kolei pozwala programistom zapomnieć o komunikacji pomiędzy aplikacją kliencką, a serwerem i pisać frontendowe komponenty tak jakby miały bezpośredni dostęp do bazy danych. 

Twórca Blitz.js w zeszłym tygodniu ogłosił pivot frameworku. W nadchodzących miesiącach porzucony zostanie fork Next.js, o którego opierało się całe rozwiązanie. Sam framework zostanie przepisany, w taki sposób, aby współpracować właściwie z dowolnym narzędziem do renderowania po stronie serwera. W podlinkowanym RFC oprócz Next.js wspomniany  jest również Remix i SvelteKit, ale nie jest to zamknięta lista.

Ciężko odmówić racjonalności podjętym decyzjom. Pomimo początkowego szybkiego wzrostu popularności frameworku, w ciągu ostatniego roku Blitz.js tygodniowo pobierany był około 5000 razy, gdzie Next.js miał tych pobrań ponad 2 miliony. Po ponad dwóch latach trwania projektu oczywistym staje się, że podjęcie walki z rynkowym gigantem będzie niemożliwe, a znaleziona nisza zbyt mała, żeby utrzymać projekt przy życiu. Jeśli twórcom Blitz.js rzeczywiście uda się stworzyć narzędzie niezależne od frameworku i przy tym zachować obecny Developer Experience to rynek potencjalnych klientów zdecydowanie się poszerzy.

Jeśli jesteście zainteresowani tym jak będzie wyglądać nowe wcielenie Blitz.js, to w zalinkowanym  poniżej RFC znajdziecie krótki szkic nowej architektury. Na razie na próżno szukać konkretnych deklaracji i terminów ze strony twórców. Osobiście trzymam kciuki za projekt i z przyjemnością przekonam się czy znajdzie on dla siebie stałe miejsce na rynku.

Źródła:

https://github.com/blitz-js/blitz/discussions/3075
https://www.reddit.com/r/javascript/comments/rixypj/blitz_is_pivoting_what_do_you_think/

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

2. Ember 4.0

Tuż przed świętami mamy dobre wieści dla wszystkich fanów Embera (jeśli nie jest to już gatunel wymarły)  – w minionym tygodniu ukazała się finalna wersja 4.0 tego frameworka. Z notatki towarzyszącej wydaniu dowiadujemy się również, że wersja 3.28 oznaczona została jako LTS oraz, że wersja 4.0 nie zawiera istotnych nowości. Zmiana numerka z przodu związana jest z porzuceniem nie wspieranych już API. 

Źródła:

https://blog.emberjs.com/ember-4-0-released/

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

3. Typowane formularze dla Angulara

Słabe typowanie formularzy to jedno z najczęściej słyszanych zarzutów wobec Angulara. Co prawda społeczność przygotowała już swoje biblioteki adresujące ten problem, ale w tym tygodniu zabrał się za niego sam zespół Angulara. Na githubie pojawiło się RFC nowej architektury i w kolejnych akapitach przyjrzymy się mu pokrótce.

Do tej pory przy tworzeniu reaktywnych formularzy właściwie całe API oparte było o typ any. RFC sugeruje silne otypowanie API. Na pozór wydaje się to zadaniem banalnie prostym, ale należy pamiętać, że reaktywne formularze nie są niemutowalnym obiektem. W API znajdziemy metody umożliwiające dynamiczne dodanie i usunięcie pola, a do tego dochodzi możliwość zagnieżdżania formularzy. Autorzy RFC zdecydowali się udostępnić mutowalne metody tylko dla pól oznaczonych jako opcjonalne. Oczywiście podobnych rozterek jest więcej, więc zainteresowanych odsyłam do samego RFC, które znajdziecie w źródłach.

const partyForm = new FormGroup({
  address: new FormGroup({house: new FormControl(1234),
                          street: new FormControl('Powell St')}),
  formal: new FormControl(false),
  foodOptions: new FormArray([])
});

const partyDetails = partyForm.getRawValue(); // previously any object, now `Party` object 
const where = partyForm.get('address.street')!.value; // previously typed as any now `string`
partyForm.controls.formal.setValue(true); // previously param had type any now `boolean`

Jeśli usprawnione formularze trafią do Angulara to aby zachować kompatybilność wsteczną wszystkie formularze w naszym kodzie automatycznie dostaną typ any. Może niezbyt to eleganckie, ale na pewno ułatwi migrację.

typealias AnyForUntypedForms = any; 

const cat = new FormGroup<AnyForUntypedForms>({
    name: new FormControl<AnyForUntypedForms>('bob'),
    lives: new FormControl<AnyForUntypedForms>(9),
});

Jak pewnie zdążyliście zauważyć do tej pory nie wspomniałem jeszcze o Template Driven Forms. Niestety formularze takie póki co nie doczekają się usprawnień bo jak tłumaczą autorzy RFC template’y w Angularze nie posiada API umożliwiającego dodanie typowania. Równolegle prowadzone są dyskusje nad dodaniem takiego API, ale póki co nie możemy liczyć na żadne konkrety.

Na zakończenie wspomnę jeszcze, że RFC dotyczące samodzielnych komponentów zostało zamknięte. Jeśli do Angulara 14 trafią zarówno samodzielne komponenty jak i typowane formularze, to ja nie mogę się już doczekać!

Źródła:

https://github.com/angular/angular/discussions/44513