![[The AI Show Episode 145]: OpenAI Releases o3 and o4-mini, AI Is Causing “Quiet Layoffs,” Executive Order on Youth AI Education & GPT-4o’s Controversial Update](https://www.marketingaiinstitute.com/hubfs/ep%20145%20cover.png)
![Apple's New Ads Spotlight Apple Watch for Kids [Video]](https://www.iclarified.com/images/news/97197/97197/97197-640.jpg)
_Andy_Dean_Photography_Alamy.jpg?width=1280&auto=webp&quality=80&disable=upscale#)
![Here’s the Pebble smartwatch reboot in action, and how much tariffs might cost you [Video]](https://i0.wp.com/9to5google.com/wp-content/uploads/sites/4/2025/03/core-2-duo-smartwatch-3.jpg?resize=1200%2C628&quality=82&strip=all&ssl=1)
![[Weekly funding roundup April 26-May 2] VC inflow continues to remain downcast](https://images.yourstory.com/cs/2/220356402d6d11e9aa979329348d4c3e/WeeklyFundingRoundupNewLogo1-1739546168054.jpg)
Still typing *ngFor, *ngIf, and *ngSwitch out of habit? You’re not alone. After years of working with legacy Angular, my muscle memory made it hard to switch to the latest Angular control flow syntax. But with one simple trick, I finally made the shift—and it improved both my code and performance. In this post, I’ll show you how to ditch the old directives and get comfortable with Angular’s new control flow in no time The Simple Trick? Let ESLint Do the Work for You Instead of forcing myself to remember, I let ESLint catch me in the act. Angular now supports ESLint rules that can warn or error when you use legacy structural directives like *ngFor, *ngIf, and *ngSwitch and instead suggest using the new control flow syntax @for, @if, @switch. Before Eslint Rule: After Eslint Rule: After adding the rule code editor highligts the error Solution: Add This ESLint Rule to Your Project To make the switch easier, you can add the following rule to your eslint.config.js under the html rules section: { files: ["**/*.html"], extends: [ ...angular.configs.templateRecommended, ...angular.configs.templateAccessibility, ], rules: { "@angular-eslint/template/prefer-control-flow": "error" }, } "@angular-eslint/template/prefer-control-flow": "error" Once you add this rule, run ng lint to catch any instances of the old directives: 12:37 error Use built-in control flow instead of directive ngIf @angular-eslint/template/prefer-control-flow 16:15 error Use built-in control flow instead of directive ngIf @angular-eslint/template/prefer-control-flow Benefits of Using the New Syntax Switching to Angular’s new control flow syntax isn’t just about cleaner code—it’s also about performance improvements. The new directives are optimized to work faster, which can make a noticeable difference in larger applications. Final Thoughts Switching from *ngIf, *ngFor, and *ngSwitch to Angular’s new control flow syntax can be a tough habit to break—but with the right ESLint rules in place, the transition becomes effortless. You’ll write cleaner, more performant code without having to constantly remind yourself to use the new syntax. Want to take it a step further? Combine this lint rule with a commit-stage linting setup to automatically prevent legacy control flow usage from making it into your codebase. In this related guide, I walk you through how to do exactly that:
Still typing *ngFor, *ngIf, and *ngSwitch out of habit? You’re not alone. After years of working with legacy Angular, my muscle memory made it hard to switch to the latest Angular control flow syntax. But with one simple trick, I finally made the shift—and it improved both my code and performance. In this post, I’ll show you how to ditch the old directives and get comfortable with Angular’s new control flow in no time
The Simple Trick? Let ESLint Do the Work for You
Instead of forcing myself to remember, I let ESLint catch me in the act.
Angular now supports ESLint rules that can warn or error when you use legacy structural directives like *ngFor, *ngIf, and *ngSwitch and instead suggest using the new control flow syntax @for, @if, @switch.
Before Eslint Rule:
After Eslint Rule:
After adding the rule code editor highligts the error
Solution: Add This ESLint Rule to Your Project
To make the switch easier, you can add the following rule to your eslint.config.js under the html rules section:
{
files: ["**/*.html"],
extends: [
...angular.configs.templateRecommended,
...angular.configs.templateAccessibility,
],
rules: {
"@angular-eslint/template/prefer-control-flow": "error"
},
}
"@angular-eslint/template/prefer-control-flow": "error"
Once you add this rule, run ng lint to catch any instances of the old directives:
12:37 error Use built-in control flow instead of directive ngIf @angular-eslint/template/prefer-control-flow
16:15 error Use built-in control flow instead of directive ngIf @angular-eslint/template/prefer-control-flow
Benefits of Using the New Syntax
Switching to Angular’s new control flow syntax isn’t just about cleaner code—it’s also about performance improvements. The new directives are optimized to work faster, which can make a noticeable difference in larger applications.
Final Thoughts
Switching from *ngIf, *ngFor, and *ngSwitch to Angular’s new control flow syntax can be a tough habit to break—but with the right ESLint rules in place, the transition becomes effortless. You’ll write cleaner, more performant code without having to constantly remind yourself to use the new syntax.
Want to take it a step further? Combine this lint rule with a commit-stage linting setup to automatically prevent legacy control flow usage from making it into your codebase. In this related guide, I walk you through how to do exactly that:
