In recent months, the Angular team has been constantly surprising us with new functionalities in the subsequent framework versions. One of such novelties is a change associated with control flow in Angular templates, which, up to now, was based on directives such as *ngIf, *ngFor, etc.
Firstly – Why?
There are a few reasons. Changes, which we have been seeing in Angular for some time now, are currently available in other JS frameworks. Angular wants to catch up on its rivals a little, however, it is not done in a haphazard way. Only those functionalities that gained traction from developers and were marked as valuable by the Angular team itself are being added. The same case is with changes associated with control flow. One of the reasons is creating it similarly to other frameworks to unify the approach, which is supposed to make improvements concerning DX.
Another vital aspect is the implementation of signal-based components. They will be based on a new change detection system, which will work without zone.js (which is often considered to be one of Angular’s biggest gripes). The zoneless approach in these components makes it impossible for any of the current directives to work in them because they are grounded on zone.js. The refractor of the present directives was contemplated by the Angular Team. However, it was associated with great risk and implementation of potential bugs, which could appear in currently existing components and approaches.
Other reasons are:
- New syntax is supposed to be flexible and to work with many kinds of templates, including if-elseif-else and switch-case. It is also a separation of syntax from HTML elements, which is an important and great step to more readable code.
- New syntax is supposed to be flexible, making it possible to adjust to every use case (if vs for vs switch).
What approaches were considered?
There were at least a couple of suggestions, but the final battle took place between #-syntax and @-syntax!
Here are some examples of both representations:
Present 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 }} } |
Present 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> } } |
It was not an easy choice, which was based on feedback from the community, Google Developer Experts, and Google’s staff members, who work with Angular on a daily basis. The majority preferred the @-syntax approach, which will indeed be presented in the Angular 17 version, which is supposed to be released within 2 months.
Another thing that we do not currently have in Angular by default (it is possible, however it requires a lot of work) is a deffer loading.
Why do we need a Defer?
To make the loading of applications effective, it requires a holistic approach to postponed loading, which takes into account rendering on the client’s part as well as on the server’s. Even now, it is possible to operate on lazy loading with routers and dynamic imports, however sometimes, it may be a complex and error-prone process. @Defer, a new basic framework mechanism, was designed to simplify postponed loading.
Main goals:
- Ensuring predictability and easiness of use.
- Reducing the time needed for initial page loading by postponing loading of elements with lower priority.
- Extending postponed loading on directives and pipes, not only on components.
- Trouble-free integration of postponed loading with hydration in order to maximise the gains.
Use of @defer:
- Represented in templates as @defer, it asynchronously downloads dependencies.
- Developers can replace placeholder content with lazily loaded content, using the triggers:
</span><b>onand</span><b>when
123@defer(on viewport) {<calendar-cmp></calendar-cmp>} - when serves to determine imperative conditions.
- on terms predefined event triggers, such as interaction, timer and much more.
- You can use many triggers simultaneously.
- Optionally a block @placeholder, can be defined to display the content before launching block @defer.
- Optionally a block @loading, can be used to define the content during downloading the dependencies.
- @defer also enables @error block, used to service loading errors.
Behaviour during rendering on the server’s side:
During rendering on the server, defer blocks always render placeholders (or nothing if the placeholder is not defined), ignoring the triggers.
Potential for the future
Partial Hydration: Angular’s way to rendering on the server’s side includes research on extending hydration implementation to operate on partial hydration without hydrating the content rendered on the server’s side until certain trigger conditions are met. Defer can be extended in order to support such functionality.RFC @defer promises a revolution in the effectiveness of loading, making it more predictable and user-friendly. It offers a complex solution for postponed loading with exciting potential for future improvements.
@-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! } |
Conclusion
Implementing new syntax for control flow in Angular is another crucial step in the framework’s development process. It is a response to developer’s expectations, growing competition, and pursuit of improvement in Developer Experience.
Acceptance of @-syntax approach, based on community and experts’ feedback, forecast a fascinating future for Angular. New possibilities, syntax separation from HTML, and flexibility in templates’ use pave the way for great, long-awaited improvements.
It is worth being up to date with these changes and getting ready for Angular 17, which may put a flesh on many world-shaking changes for projects. We’re impatiently waiting for what the future holds and new solutions, which will undoubtedly influence our day-to-day programming challenges.
Angular Team keeps up with the times, and we, as a community, can expect even more thrilling novelties. Being a part of this evolution is definitely worth it.
In closing, we warmly encourage you to share your opinion, as it is extremely valuable for us. Does new syntax for flow control meet your expectations? Do you see a potential in these changes? Or do you have any suggestions for upcoming improvements? Let us know in the comments or through direct contact.
Pingback: Angular 17 - Introduction to Angular Renaissance - Angular.love