Angular 19 New Control Flow: From *ngIf/*ngFor to @if/@for Syntax

As of the latest features in Angular, there has been a significant shift in how control flow is handled in templates. While Angular 17 introduced the new template syntax with @if, @for, and @switch, there remains some confusion about whether the traditional structural directives like *ngIf and *ngFor are officially deprecated in newer versions like Angular 19. This post clarifies the current status and provides guidance for Angular developers navigating these changes.

The New Angular Control Flow Syntax

Angular 17 introduced a major change to template syntax, replacing the familiar structural directives (*ngIf, *ngFor, *ngSwitch) with a new control flow syntax (@if, @for, @switch). This new approach embeds control flow directly within HTML, placing control structures outside of the tags instead of as attributes on them^1_1.

For example, the traditional approach using structural directives looked like this:

<ul>
 <ng-container *ngFor="let country of countries">
 <li></li>
 </ng-container>
</ul>

With the new template syntax, the same code would be:

<ul>
 @for (country of countries; track country.name) {
 @if (country.locale === filteredLocale) {
 <li></li>
 }
 }
</ul>

This shift represents a fundamental change in how Angular templates are structured, moving toward a paradigm that more closely resembles JavaScript syntax extensions like JSX in React^1_1. The choice of the @ symbol was inspired by the Svelte framework, and while the Angular team initially had different syntax in mind, community preferences prevailed^1_1.

Why The Change?

The introduction of the new syntax wasn't merely cosmetic. The Angular team had been working on prototypes and plans for Signal Components long before version 16, and discovered that improvements to the current Structural Directives were necessary for compatibility with Signal Components^1_1.

Additionally, the Angular team identified several limitations with the traditional structural directives, including:

1. Lack of simple else statements or elseif in *ngIf
2. The requirement to explicitly import control commands
3. No native support in templates for these functionalities^1_1

The new syntax addresses these issues while also providing performance benefits as the Angular compiler can better handle built-in control flow mechanisms.

Comparing *ngIf and @if

The traditional *ngIf directive allows developers to toggle content based on conditionals by adding or removing DOM elements^1_2. The new @if syntax serves the same purpose but offers several advantages:

1. More ergonomic and less verbose syntax closer to JavaScript, making it more intuitive and requiring fewer documentation lookups^1_3
2. Automatic availability in templates without additional imports^1_3
3. Better type checking through more optimal type narrowing^1_3
4. Reduced runtime footprint, helping to decrease bundle size and improve Core Web Vitals^1_3
5. Support for else-if conditions, which wasn't directly possible with the *ngIf syntax^1_3

@if Syntax Examples

The new @if syntax supports simple conditions:

@if (showHello) {
  <h2>Hello</h2>
}

It also supports else conditions:

@if (showHello) {
  <h2>Hello</h2>
} @else {
  <h2>Goodbye</h2>
}

And it supports else-if conditions, which wasn't possible with the traditional syntax:

@if (showHello) {
  <h2>Hello</h2>
} @else if (showGoodbye) {
  <h2>Goodbye</h2>
} @else {
  <h2>Nothing to show</h2>
}

Are *ngIf and *ngFor Deprecated?

The critical question for many Angular developers is whether the traditional structural directives like *ngIf and *ngFor are officially deprecated in newer Angular versions. As of Angular 17, "The Structural Directives are not marked as deprecated, and a migration script exists to automate the process. However, it is not mandatory to switch"^1_1.

While the new syntax is designed as a stepping stone for future Signal Components and offers numerous advantages, Angular has not officially deprecated the traditional structural directives. This is likely due to the vast ecosystem of existing Angular applications that use these directives extensively.

However, the direction of the framework is clear. The Angular team is moving toward the new control flow syntax, and future features like Signal Components are being designed with this syntax in mind. This indicates that while not officially deprecated yet, the traditional structural directives will likely be phased out in future versions.

Migration Strategy

Google manages thousands of Angular applications internally, and one of their internal rules states that they must handle breaking changes themselves^1_1. For such a large codebase, manual migration would be impossible, which is why Angular provides automated scripts to refactor source code.

For Angular developers looking to migrate to the new syntax:

1. Angular provides migration scripts to automate the transition from traditional structural directives to the new control flow syntax^1_1
2. The migration is not mandatory, but recommended to stay aligned with the framework's direction
3. The Extended-Template-Syntax was initially released as a Developer Preview in Angular 17, indicating it was stable but still evolving^1_1

Future Directions: Server Components

Jeremy Elbourn, Tech Lead of the entire Angular project, has indicated that it's possible to integrate Server Components (similar to those in React) into Angular^1_1. This would involve marking blocks with @server instead of @defer, allowing them to render exclusively on the server and send only static HTML to the browser, eliminating the need for JavaScript from the server process^1_1.

This development further underscores the importance of the new control flow syntax as Angular continues to evolve.

Conclusion

While the traditional structural directives (*ngIf, *ngFor, *ngSwitch) are not officially deprecated as of Angular 17, the framework is clearly moving toward the new control flow syntax (@if, @for, @switch). This transition is driven by the need to support future features like Signal Components and to address limitations in the current structural directives.

Angular developers should consider adopting the new syntax in their projects, especially for new development, to align with the framework's direction. The availability of migration scripts makes this transition more manageable, even for large codebases.

As Angular continues to evolve toward version 19 and beyond, it's reasonable to expect that the traditional structural directives may eventually be deprecated. By adopting the new syntax now, developers can future-proof their applications and take advantage of the improved ergonomics and performance that the new control flow syntax offers.