1. rx-angular

zone.js to biblioteka, która od początku stała u podstaw Angulara. Jej głównym zadaniem jest opakowanie przeglądarkowych eventów w odpowiednie API, dzięki któremu Angular może przy okazji każdego zdarzenia, uruchomić mechanizm wykrywania zmian. Proces ten pozwala przypisać wartość do zmiennej w komponencie i zostanie ona automatycznie odświeżona na interfejsie użytkownika. Problem jest jeden: programiści stracili kontrolę nad uruchomieniem mechanizmu wykrywania zmian, a co za tym idzie nad wydajnością swoich aplikacji. Odpowiedzią na ten problem jest zmiana ChangeDetectionStrategy na OnPush, co w sporym skrócie wprowadza następujący kontrakt: komponent zmienia swój stan tylko, kiedy zmieniają się jego parametry wejściowe. Może się wydawać, że w takim scenariuszu zone.js staje się zbędny. Niestety sporo angularowych rozwiązań jest mocno powiązanych z zone.js (np. async pipe przestanie działać, jeśli pozbawić go dostępu do tej biblioteki). rx-angular to zestaw narzędzi, który idzie o krok dalej i będzie wspierać programistów w tworzeniu aplikacji całkowicie pozbawionych zone.js.

Na rx-angular składają się trzy niezależne parkiety: @rx-angular/cdk, @rx-angular/state i @rx-angular/template. Pierwszy z nich ma pomagać w tworzeniu wydajnych komponentów. Na ten moment dostarcza on przede wszystkim zestaw funkcji do sterowania zone.js, pozwalających stopniowo go wyłączać, aby ostatecznie pozbyć się go całkowicie.

Druga z wymienionych bibliotek pozwala na zarządzanie stanem komponentu w reaktywny sposób (i oczywiście działa przy wyłączonym zone.js). W pierwszej chwili bardzo skojarzyło mi się to z reactowymi hookami i jeśli przyjrzeć się temu bliżej, to rzeczywiście działa to bardzo podobnie do useState.

@Component({
	selector: 'app-stateful',
	template: ` <div>{{ title$ | async }}</div> `,
	providers: [RxState],
})
export class StatefulComponent {
	readonly title$ = this.state.select('title');

	@Input() set title(title: string) {
		this.state.set({ title });
	}

	constructor(private state: RxState<{ title: string }>) {}
}

Na deser zostawiłem sobie najciekawszą z trzech paczek. @rx-angular/template zawiera w sobie dwie nowe dyrektywy. Dyrektywa `push` jest odpowiedzią na wspomniany w pierwszym akapicie problem z async. Pozwala ona więc zasubskrybować się do strumienia danych, ale nie wymaga do tego zone.js. Druga to rxLet, i jest słodzikiem syntaktycznym (uwielbiam to spolszczenie) na `*ngIf=”(stream$ | async); let value”`.

<ng-container
	*rxLet="observableNumber$; let n; let e = $error, let c = $complete"
>
	<app-number [number]="n" *ngIf="!e && !c"></app-number>
	<ng-container *ngIf="e"> There is an error: {{ e }} </ng-container>
	<ng-container *ngIf="c"> Observable completed: {{ c }} </ng-container>
</ng-container>
<hero-search [term]="searchTerm$ | push"> </hero-search>
<hero-list-component [heroes]="heroes$ | push"> </hero-list-component>

To co jest tak naprawdę ciekawe w tym pakiecie to dodatkowy parametr, jaki mogą przyjmować te dyrektywy, czyli render strategy. Na ten moment dostępne są tylko strategie znane z podstawowego Angulara, ale w planach jest implementacja strategii, które pozwolą na priorytetyzację renderowania poszczególnych komponentów. Kiedy obiecane strategie zostaną dostarczone to myślę, że pakiet ten stanie się jednym z podstawowych narzędzi przy optymalizacji angularowych aplikacji.

W tej beczce miodu jest też niestety łyżka dziegciu. rx-angular na razie dostępny jest w wersji beta i nie wiadomo, kiedy możemy się spodziewać wypuszczenia stabilnej wersji.

Źródła:

https://github.com/rx-angular/rx-angular

2. Porównanie narzędzi nowej generacji do budowania aplikacji

Jeśli śledzicie nasze frontendowe przeglądy od jakiegoś czasu, to pewnie wiecie, że z zapartym tchem śledzę nowe narzędzia do budowania aplikacji (a esbuild absolutnie skradł moje serce). W poprzednich edycjach starałem się przemycić Wam co nieco o Vite czy Snowpacku, ale z moją skromną wiedzą i ograniczeniami naszej formuły były to raczej marne próby. Jeśli Was też interesują następcy Webpacka i Rollupa, to w źródłach znajdziecie prawdziwą kopalnię wiedzy na ten temat. Gdybym miał wybrać jeden artykuł, który polecam w tym temacie, to byłby to właśnie ten podlinkowany poniżej. Przygotujcie tylko gigantyczny kubek kawy, bo nie jest to krótka lektura ☕️.

Źródła:

https://css-tricks.com/comparing-the-new-generation-of-build-tools/

3. Node.js 16 i Deno 1.9

Wśród frontendowych frameworków i bibliotek nie działo się w tym tygodniu właściwie nic ciekawego. W związku z tym postanowiłem rzucić okiem na to co działo się po backendowej stronie JavaScriptu. Nagłówki wyglądały obiecująco, bo dwóch największych graczy wypuściło duże aktualizacje do swoich środowisk uruchomieniowych. Kiedy wczytałem się dokładniej w aktualizacje, boleśnie przekonałem się o tym, że po drugiej stronie płotu trawa wcale nie jest bardziej zielona, a zmiany nie są ani odrobinę bardziej dynamiczne niż te po frontendowej stronie.

Nowa wersja Node to przede wszystkim podbicie wersji V8 z 8.6 na 9.0 i nowe funkcjonalności z tym związane. Łatkę stabilności dostała funkcja `setTimeout` z pakietu `promisify`. Node 16.0 będzie też pierwszą wersją dostarczającą natywne wsparcie dla Apple Silicon.

Jeśli mówimy już o M1 to jak podobała wam się ostatnia konferencja Apple? Ktoś z Was czekał na iPad i iMac z M1?

W nowej wersji Deno dzieje się nieco więcej, ale ciężko mówić tutaj o przełomowych zmianach. Największą nowością jest natywne wsparcie dla serwera HTTP/2 i przyśpieszenie komunikacji z działającym pod spodem Rustem. Ciekawie wygląda też wsparcie dla dynamicznego dopytywania o dostęp zamiast definiowania ich upfront.

Źródła:

https://nodejs.medium.com/node-js-16-available-now-7f5099a97e70
https://deno.com/blog/v1.9


Pamiętajcie, żeby spróbować Vived, jeśli chcesz otrzymywać tego typu treści spersonalizowane pod Ciebie!