Alex Rickabaugh on Rethinking Control Flow
Alex Rickabaugh, who leads the Angular framework team, took the time to lay out the reasoning behind introducing a fresh control flow syntax. Right now, the standard approach relies on structural directives like *ngIf, *ngFor, and *ngSwitch.
These directives are not executed in an imperative way, similar to a JavaScript if statement. Rather, they serve as hints for the compiler. The compiler breaks a component down into multiple views, where each view represents a set of static DOM elements. The structural directives act as the condition that determines when a particular view gets created.
Furthermore, the compiler produces an <ng-template> and treats the structural directive as a regular property binding attached to it.
Despite its widespread use, this method has several drawbacks.
- The syntax can feel awkward and unintuitive for developers.
- Type checking has gaps, particularly when working with the
elseclause. - Using an
<ng-container>is necessary when you need a directive without creating a new DOM element. The same holds true when you want to apply multiple directives, as only one can be placed on a single element. - Coordinating multiple directives that depend on each other can quickly become complicated.
The upcoming RFC for control flow aims to tackle these problems. It proposes an extension to the existing template syntax.
Alex noted that a trade-off of this new direction is stepping away from allowing developers to create such features themselves, which he referred to as "user space." The new control flow will be built directly into the template as a core feature.
The most significant point to remember is that *ngIf, *ngFor, and *ngSwitch could potentially be marked as deprecated in the future. The exact timeline is still open for discussion, but the goal is to establish a single, unified way for handling central tasks in Angular.
Minko Gechev Discusses Angular Air Plans
Minko Gechev, the product lead for Angular, appeared on the Angular Air podcast and confirmed that Signal-based components are slated for a developer preview release in Angular 17. The signals library, which was introduced in Angular 16, is expected to be promoted to a stable status.
This new Signal-based component type is designed to operate without requiring zone.js. The team suggests that developers should begin adopting signals in parts of the application where performance is a key concern.
A noteworthy point is that creating an automatic migration path to signals is not a viable option.
Brandon Roberts Provides AnalogJS Update
Brandon Roberts offered an overview of the current state of AnalogJS, a meta-framework built on Angular. It comes prepackaged with features such as Vitest integration, file-based routing, API route handling, and server-side rendering and generation capabilities.
Clarifying "Developer Preview" and the Future of Forms
The most recent ng-conf recordings provided two important clarifications.
A feature released as a "developer preview" should not be mistaken for a beta. It is fully operational and pre-stable, meaning it works as intended, but the specific API contract is not finalized and could still undergo changes.
Another topic discussed was the long-term ambition to overhaul forms. At this stage, the Angular team is still exploring the different paths they could take. One possibility is that the Reactive and Template-driven approaches could be unified once more.
