🔧🚫 Stop Using ngIf and ngFor: Enforce Angular's New Control Flow with ESLint ✅

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:
👉 Maintain Code Quality Like a Big Tech Team Without Paying for Expensive Automation

By combining ESLint rules with pre-commit hooks, you ensure that your team consistently follows the latest Angular best practices—with zero manual effort.

🖼️ Banner generated using OpenAI Sora