DEV Community

Cover image for Why I like the "Built-In Control Flow" idea
Evgeniy OZ
Evgeniy OZ

Posted on • Updated on • Originally published at Medium

Why I like the "Built-In Control Flow" idea

A new RFC in Angular, "Built-In Control Flow" excited me (and many others), but not everyone. Some don't like the change per se, some don't like that some structural directives will be deprecated, some don't like how the new syntax look, and so on. Here I'll explain why I like this new idea.

Structural directives should not be directives

They are simply not related to the component they are applied to.
Look at this code:

<ul>
  <li *ngFor="let item of items">
    {{item.label}}
  </li>
</ul>
Enter fullscreen mode Exit fullscreen mode

Here ngFor is not an attribute of a rendered element li - it defines if that element should be rendered at all.

Now let's complicate our code a bit, and only render items that have non-empty label:

<ul>
  <ng-container *ngFor="let item of items">
    <li *ngIf="!!item.label">
      {{item.label}}
    </li>
  </ng-container>
</ul>
Enter fullscreen mode Exit fullscreen mode

Because we can't apply more than one structural directive to an element, we moved ngFor away from li and it didn't affect how li looks or behaves. 

If we can move it out, then it was not an "attribute" of li, it was a control flow mechanism, implemented as a directive - in the second example it's still a directive, applied to the artificial element ng-container. It should be implemented as a control flow mechanism and should not look like an attribute of some element.

It makes code more compact

Even simple "if-else" in Angular templates look awkward right now. Cases like "if-else if-else" quickly become confusing and too large:

<ng-container *ngIf="item.type==='email'; else nonEmail">
  <a href="mailto:{{item.ref}}">{{item.ref}}</a>
</ng-container>

<ng-template #nonEmail>
  <ng-container *ngIf="!!item.label; else noLabel">
    <a href="{{item.ref}}">{{item.label}}</a>
  </ng-container>

  <ng-template #noLabel>
    <div>Wrong link</div>
  </ng-template>
</ng-template>
Enter fullscreen mode Exit fullscreen mode

Compare it with:

{#if item.type==='email'}
  <a href="mailto:{{item.ref}}">{{item.ref}}</a>
{:elseif !!item.label }
  <a href="{{item.ref}}">{{item.label}}</a>
{:else}
   <div>Wrong link</div>
{/if}
Enter fullscreen mode Exit fullscreen mode

More powerful than user-land directives

Because of the "built-in" nature of the new control flow, the framework can make some "preparations" and optimizations during the "build" phase. It opens the door to things that weren't possible before (or were quite tricky to implement). And a great example is #defer (see "RFC: Deferred Loading"). 

Removes the micro-syntax limitations

We we'll get much better type-checking and type-narrowing.
If you haven't heard about micro-syntax: every time you write

<li *ngFor="let item of items; index as i; trackBy: trackByFn">{{item}}</li>
Enter fullscreen mode Exit fullscreen mode

Angular translates it into the long form of ngFor (that, I'm sure, very few developers use on a regular basis):

<ng-template ngFor 
             let-item 
             [ngForOf]="items" 
             let-i="index" 
             [ngForTrackBy]="trackByFn"
>
  <li>{{item}}</li>
</ng-template>
Enter fullscreen mode Exit fullscreen mode

So, developers had to create micro-syntax to make that shorthand possible, to don't make you use the long form with its awkward API. Built-in control flow removes that awkwardness and gives better type-narrowing.

Third-party structural directives will remain

There are well-known and quite handy structural directives like rxFor, ngrxLet — they will not be deprecated or affected in any way. The concept of structural directives itself will not be deprecated: you can still create and use them. They can not get all the power that built-in control flow has, but their existing features are not going to go anywhere.

I understand the reasoning of the Angular team why they don’t want to make the new control flow syntax extensible — once they’ll provide an API, they are limited by the given API. Such API would have a chance to be beneficial for the third-party directives, but the unhindered evolution of such a defining feature of the framework is more important.

It's a chance to greatly improve Angular

Control flow is an essential feature, one of the core features of the framework. Any improvements in this area will be extremely beneficial for every developer.

Built-in control flow removes control flow from "user-land code" and gives full control to the framework - it's not just some structural directives anymore, so Angular can do more things in a more optimal way. I believe that #defer is just the first example of many nice features we'll get out of this idea.


💙 If you enjoy my articles, consider following me on Twitter, and/or subscribing to receive my new articles by email.

🎩️ If you or your company is looking for an Angular consultant, you can purchase my consultations on Upwork.

Top comments (0)