Angular: Release of version 4

When Angular version 4 was released in March 2017, people wondered „What has happened to version 3?“ And another question of particular concern for (us) developers was „What is new in Angular version 4?“ In this article we address these questions.

Semantic versioning

In order to answer the first question why Angular version 3 has been omitted let us take a look at the versioning convention adopted by the Angular development team. According to Igor Minar in the opening keynote for version 4, the Angular team uses semantic versioning for their releases. By means of the illustration shown in Fig. 1, we explain in the following how this system works.

ng-semantic_versioning
Fig. 1: Example of semantic versioning for Angular releases. Release cycles are indicated.

The version specification consists of three numbers: one for major versions, one for minor versions and, lastly, one for patches. A patch is supposed to introduce no new features or breaking changes to Angular. A minor version change can feature new functionalities but no breaking changes. A major version release typically entails new features and potentially breaking changes. As indicated by Fig. 1, new patches are released every week, minor versions every month and major versions every half year.

The reason for skipping version 3 is quite subtle. While all but one Angular module were still at major version number 2, the routing module had already advanced to version 3. Eventually, the Angular team desired to have consistent version numbers for all modules. Hence, when the next major release was due, all modules jumped to version 4. Thus, Angular version 3 was omitted. Also, the development team decided to suppress the version number in the name (as it is going to change every half year, anyway,) and just call the framework „Angular“.

New features in version 4

In this part we talk about what is new in Angular version 4. Note that we do not discuss passive changes like the enhanced performance of the angular-cli or the better compression rate for the distributed app. Instead we demonstrate the appliance of three new features in version 4. These are the new *ngIf, the new possibility to introduce local variables via the as keyword and the email validator.

The new *ngIf

Since version 4 the *ngIf statement can be extended by a then and an else statement, both optional. To see how the new *ngIf works, first, let us take a look at Listing 1 below.

<div *ngIf="condition">
  <p>This text is only visible if the condition is <em>true</em>.</p>
</div>

<div *ngIf="!condition">
  <p>This text is only visible if the condition is <em>false</em>.</p>
</div>
Listing 1: Example of how the *ngIf statement used to be formulated in version 2.

Consider that in an Angular component we have a boolean condition. In our app we want to display different content depending on whether the condition evaluates to true or false. As shown in Listing 1, in version 2 this was realized by having two separate DOM elements, one checking for condition and the other for !condition — but wait, this feels a little clumsy. If we test condition in line 1 why do we have to repeat this step in line 5 again?

Now, since version 4, we can solve this in a more elegant way as illustrated in Listing 2. The html code snippet shown there does the same as the one in Listing 1, only it extends the *ngIf statement with an else statement to get the result we want. In this example the elseBlock defines which content is to be displayed if the condition evaluates to false. Note that this content must be encapsulated in an ng-template element. In line 5 we also register this element as „elseBlock“ in the DOM (via #elseBlock). Interestingly, the angular-cli does not care where the elseBlock is declared in the html. Instead the element with the *ngIf expression serves as an outlet for the conditional content.

<div *ngIf="condition; else elseBlock">
  <p>This text is only visible if the condition is <em>true</em>.</p>
</div>

<ng-template #elseBlock>
  <p>This text is only visible if the condition is <em>false</em>.</p>
</ng-template>
Listing 2: Example of an *ngIf-else statement featured since version 4.

Finally, in Listing 3, we show an example of an if-then-else statement. In addition to the elseBlock we had before, we now also include a thenBlock. This block is displayed if the condition evaluates to true. It is apparent that the thenBlock works in a similar way as the elseBlock. However, it is important to notice that, if a then statement is included into the *ngIf expression, the content of the element attached to the *ngIf is completely ignored (as statet in line 2 of Listing 3).

<div *ngIf="condition; then thenBlock; else elseBlock">
  <p>This part is completely ignored, now.</p>
</div>

<ng-template #thenBlock>
  <p>This text is only visible if the condition is <em>true</em>.</p>
</ng-template>

<ng-template #elseBlock>
  <p>This text is only visible if the condition is <em>false</em>.</p>
</ng-template>
Listing 3: Example of an *ngIf-then-else statement featured since version 4.

Let us summarize what we have learned in this section. With the new *ngIf we can handle the evaluation of a boolean expression in only one line (cf. Listing 3, line 1). This element is used as outlet for the conditional content. By means of (optional) then and else blocks, which need be embedded in ng-template elements, we can keep our DOM tidy and well organized.

Create local variables with the as keyword

Another new feature is the possibility to define a local variable using the as keyword. In the example in Listing 4 we label the index parameter inherent to *ngFor as idx and insert it in the subsequent line with one-way data binding. The as keyword is also quite useful to relabel (lengthy) variable names in order to make our html code cleaner. Another nice application of the as keyword in combination with asynchronous data loading is described in this article.

<div *ngFor="let item of itemList; index as idx">
  {{idx}}. {{item}} 
</div>
Listing 4: Example of an appliance of the as keyword featured since version 4.

The new email validator

In many forms an email address is required. Formerly, validity of the address needed be checked against a manually written regex. Since version 4 we can now use the email validator as illustrated in Listing 5 (the validator is the last occurrence of the word „email“). Validating an email address never has been that easy!

<input type="email" [(ngModel)]="user.email" name="email" email>
Listing 5: The new email validator featured since version 4.

Conclusion

Angular version 4 has brought a lot of improvement in terms of performance of the framework. Many new features like the new *ngIf, the as keyword and the email validator discussed in this article have been introduced to make our life as programmers easier and to help us to keep our code cleaner. With major version releases every six months we are looking forward for many new features yet to come.

Dieser Beitrag wurde unter Frontend Development abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s