W ostatnich miesiącach Angular team co rusz zaskakuje nas nowymi funkcjonalnościami w kolejnych wersjach frameworka. Jedną z takich nowości jest zmiana związana z control flow w templatkach Angulara, które dotychczas opierały się na dyrektywach takich jak *ngIf, *ngFor itd.
Po pierwsze – Dlaczego?
Powodów jest kilka. Zmiany, które w ostatnim czasie obserwujemy w Angularze już od jakiegoś czasu są dostępne w innych jsowych frameworkach. Angular chce nieco nadgonić za konkurencją. Aczkolwiek nie robi tego na ślepo – wybiera i dodaje te funkcjonalności, które spotkały się z duża aprobatą developerów i sam Angular team uważa je za wartościowe. I tak właśnie jest też ze zmianami związanymi z control flow. Jednym z argumentów jest zrobienie tego na wzór innych frameworków, tak aby ujednolicić nieco podejście co ma za sobą pociągnąć usprawnienia w zakresie DX.Kolejnym bardzo istotnym powodem jest wprowadzenie signal-based components. Te będą oparte o nowy system detekcji zmian, który będzie funkcjonował bez zone.js (często obecnie uważany za jedną z większych bolączek Angulara). W związku z podejściem zoneless w tych komponentach, żadne z obecnych dyrektyw nie działałyby w tychże komponentach ponieważ są one oparte na zone.js. Angular Team rozważał refaktor obecnych dyrektyw ale wiązało się to z bardzo dużym ryzykiem, wprowadzeniem potencjalnych bugów, które mogłyby wystąpić w obecnie funkcjonujących komponentach i podejściach.
Jako kolejne powody wymienia się:
- Nowy syntax ma być elastyczny i działać z wieloma rodzajami template’ów, w tym z if-elseif-else i switch-case. To także oddzielenie składni od elementów HTML, co jest ważnym krokiem ku czytelniejszemu kodowi.
- Nowa składnia ma być elastyczna umożliwiająca dostosowanie do każdego przypadku użycia (if vs for vs switch).
Jakie podejścia były rozważane?
Propozycji było co najmniej kilka, ale finalna batalia rozgrywała się pomiędzy #-syntax oraz @-syntax!
Poniżej kilka przykładów obydwu reprezentacji:
Obecny syntax
|
1 2 3 |
<div *ngIf="users$ | async as users"> {{ users.length }} </div> |
#-syntax
|
1 2 3 |
{#if users$ | async; as users} {{ users.length }} {/if} |
@-syntax
|
1 2 3 |
@if (users$ | async; as users) { {{ users.length }} } |
Obecny syntax
|
1 2 3 4 5 6 7 |
<ng-container *ngFor="let item of items; let i = index; trackBy: trackByFn"> <li>{{ item.name }}</li> </ng-container> <ng-container *ngIf="items.length === 0"> <li>There are no items.</li> </ng-container> |
#-syntax
|
1 2 3 4 5 |
{#for item of items; track item.name} <li> {{ item.name }} {:empty} <li> There are no items. {/for} |
@-syntax
|
1 2 3 4 5 6 |
@for (let item of items; trackBy: item.name) { <li>{{ item.name }}</li> @empty { <li>There are no items.</li> } } |
Decyzja nie była łatwa, opierała się ona na feedbacku od community, Google Developer Expert oraz od pracowników Google’a, którzy na co dzień pracują z Angularem. W większości głosy przeważały za podejściem </span><b>@-syntax i to właśnie to podejście zostanie nam przedstawione w wersji 17, której możemy spodziewać się w przeciągu dwóch nadchodzących miesięcy.
Jest również coś czego obecnie nie mamy w Angularze by default (Da się, ale trzeba się pobawić). Mowa o deffer loading.
Dlaczego potrzebujemy Defer?
Efektywne ładowanie aplikacji wymaga holistycznego podejścia do odroczonego ładowania, które uwzględnia zarówno renderowanie po stronie klienta, jak i serwera. Chociaż Angular już teraz obsługuje leniwe ładowanie za pomocą routerów i dynamicznych importów, te metody czasami mogą być złożone i podatne na błędy. Dochodzi nam @defer, nowy podstawowy mechanizm frameworka zaprojektowany w celu uproszczenia odroczonego ładowania w Angularze.
Główne Cele:
- Zapewnienie przewidywalności i łatwości użycia
- Skrócenie czasu początkowego ładowania strony poprzez odroczenie ładowania elementów o niższym priorytecie.
- Rozszerzenie odroczonego ładowania na dyrektywy i pipe’y, nie tylko na komponenty.
- Bezproblemowa integracja odroczonego ładowania z procesem hydratacji dla osiągnięcia maksymalnych korzyści.
Korzystanie z @defer:
- Reprezentowane w szablonach jako
@defer, ten blok ładowania asynchronicznie pobiera zależności. - Programiści mogą uruchamiać zamianę z miejsca na ładowane leniwie, korzystając z warunków when i on.
123@defer(on viewport) {<calendar-cmp></calendar-cmp>} - when służy do określania warunków imperatywnych.
- on określa predefiniowane wyzwalacze zdarzeń, takie jak interakcja, timer i wiele innych.
- Można używać wielu wyzwalaczy zdarzeń jednocześnie.
- Opcjonalnie można zdefiniować blok @placeholder, aby wyświetlić zawartość przed uruchomieniem bloku
@defer. - Opcjonalnie można używać @loading, aby określić zawartość podczas pobierania zależności.
- @defer umożliwia również blok @error do obsługi błędów ładowania.
Zachowanie Podczas Renderowania po Stronie Serwera:
- Podczas renderowania na serwerze bloki defer zawsze renderują placeholder’y (lub nic gdy placeholder nie jest zdefiniowany), ignorując wyzwalacze.
Potencjał na Przyszłość
Częściowa Hydratacja: Droga Angulara do renderowania po stronie serwera obejmuje badania nad rozszerzeniem implementacji hydratacji, aby obsługiwać częściową hydratację, pozostawiając zawartość renderowaną po stronie serwera w stanie nieshydratyzowanym do momentu spełnienia określonych warunków wyzwalania. Defer może zostać rozszerzony w celu wsparcia takiej funkcjonalności.RFC @defer obiecuje rewolucję w efektywności ładowania, czyniąc ją bardziej przewidywalną i przyjazną dla użytkowników. Oferuje kompleksowe rozwiązanie dla odroczonego ładowania, z ekscytującym potencjałem na przyszłe ulepszenia.
@-syntax
|
1 2 3 4 5 6 7 8 9 10 |
@if (user.isHuman) { <human-profile [data]="user" /> } @else if (user.isRobot) { <!-- robot users are rare, so load their profiles lazily --> @defer { <robot-profile [data]="user" /> } } @else { <p>The profile is unknown! } |
Podsumowanie
Wprowadzenie nowego syntaxu dla control flow w Angularze to kolejny krok w rozwoju frameworka. To reakcja na oczekiwania deweloperów, rosnącą konkurencję i dążenie do usprawnienia Developer Experience.
Przyjęcie podejścia @-syntax, opartego na feedbacku społeczności i ekspertów, zapowiada fascynującą przyszłość dla Angulara. Nowe możliwości, oddzielenie składni od HTML oraz elastyczność w użyciu template’ów otwierają przed nami szerokie perspektywy.
Warto być na bieżąco z tymi zmianami i przygotowywać się na wersję 17 Angulara, która może przybliżyć nam przełomowe zmiany dla wielu projektów. Oczekujemy z niecierpliwością na to, co przyniesie przyszłość i jak nowe rozwiązania wpłyną na nasze codzienne wyzwania w programowaniu.
Angular Team idzie z duchem czasu, a my jako społeczność możemy oczekiwać jeszcze wielu ekscytujących nowości. Warto być częścią tej ewolucji.
I na koniec, chcielibyśmy Was serdecznie zachęcić do podzielenia się swoim feedbackiem. Wasza opinia jest dla nas niezwykle cenna. Czy nowy syntax dla kontrolowania przepływu w Angularze spełnia Wasze oczekiwania? Czy widzicie potencjał w tych zmianach? A może macie własne sugestie dotyczące przyszłych udoskonaleń? Dajcie nam znać w komentarzach lub poprzez kontakt bezpośredni.
Bardzo jestem zadowolony z faktu ze to wlasnie składnia @ ostatecznie zostanie wprowadzona. Zmiana baaardzo na plus i nie moge sie doczekac az uzyje jej w projektach
Bartek już możesz nawet zacząć się bawić, bo ta zmiana znajduje się w ostatnim release’ie – 17.0.0-next.6 (2023-09-27)
Pingback: Angular 17 - co nowego? - Angular.love
Dzięki za fajny artykuł! Podsumowanie wszystkich najważnieszych zmian w artykulie do przeczytania w 5min to jest klasa 🙂