Angular 11 Officially Released!. Compiler, routes, supports. Just some…
Tags: Angular, Angular 11, Angular Cli, Frontend, Google

What should we expect this time?

Among the most relevant aspects, we certainly find stricter types, router performance improvements and the removed support for some versions of Internet Explorer (I know colleagues who reading this news would start the day with more than a smile 😄).

Router

In this new Ng Version, the relativeLinkResolution’s router has changed its default value from “legacy” to “corrected”.

To achieve this change, the RouterModule configurations have been updated so that to use “legacy” it must be specified so as to prevent breakages during updating.

Paying attention also to router performance, ngDevMode can be used to tree-shake error messages and the type of parameter in “navigateByUrl” and “createUrlTree” is being adjusted to be more accurate.

Service worker

A new notification is added for the service-worker. We’re talking about the UnrecoverableStateError notification.

This fix solves the issue in which a broken state would arise where only parts of an application would load properly.

The reason is that the browser has evicted cached assets from the cache that cannot be found on the server anymore.

Angular compiler

For the compiler-cli, interfaces are being defined that can be used for TemplateTypeChecker. Improvements that make the compiler-cli even more performing if we think of the Template type Checking introduced in Angular 9.

In fact, three levels of type checking were introduced with that version:

basic

full

strict

In the basic mode, with this line of code <map [city]="user.address.city"> the compiler verifies that user is a property on the component class, user is an object with an address property and user.address is an object with a city property.

With this easy mode, the compiler doesn’t verify that the value of user.address.city is assignable to the city input of the <map> component.

In the full mode, Angular is more aggressive during the type checking, in fact

Embedded views (such as *ngIf or *ngFor) are checked;

Pipes have the correct return type

Local references to directives and pipes have the correct type.

Instead, we can consider strict mode a superset of full mode as it adds more restrictions and it’s only available if using Ivy.

In addition to full mode:

Verifies that component/directive bindings are assignable to their @Input()s

Obey Typescript’s strictNullChecks flag when validating the above;

Infers the correct type of components/directives, including generics.

Infers template context types where configured (for example, allowing correct type-checking of NgFor).

Infers the correct type of $event in component/directive, DOM, and animation event bindings.

in component/directive, DOM, and animation event bindings. Infers the correct type of local references to DOM elements, based on the tag name (for example, the type that document.createElement would return for that tag).

What else on Angular compiler?

One of the aspects that affect developers in a sufficiently invisible way is the addition of the “keySpan” to the “Variable node”.

We talk about “keySpan” when we put our attention on “microsyntax expressions”.

Microsyntax in Angular allows you to write:

<div *ngFor="let item of items">{{item}}</div>

instead of

<ng-template ngFor [ngForOf]="items"><div>{{item}}</div></ng-template>

..and it must:

be know ahead of time so that IDEs can parse it without knowing what is the underlying semantics of the directive or what directives are present;

translate to key-value attributes in the DOM.

Everything borns from “sourceSpan” problems.

Take a look at this example:

Unable to pinpoint a specific location within the microsyntax if an error occurs

Unable to traverse the complete AST (Abstract Syntax Tree) for a particular position

Unable for language service to provide autocomplete at a precise position

Microsyntax keywords (let & as) intermingled with a directive selector like “of”, which is not a keyword.

Introducing keySpan in TemplateBinding, the span is captured on the LHS of a binding and the LHS are identifiers like “item” and “of”.

It’s used an absolute offset and keywords like “as” and “let” are not considered.

Supports

Browser supported versions

Support is removed for Internet Explorer 9 and Internet Explorer 10 browsers as is IE mobile support.

The only version of IE still supported by Angular is IE11

Furthermore, TypeScript 3.9 support has been removed from the compiler. You should upgrade to TypeScript 4.0

What about quick reloading module?

You have surely heard during these years of HMR that stands for Hot Module Reload, which goes by another name: Hot Module Replacement.

An easier HMR support has been released. This makes it quicker to see code changes in your browser after changing. Of course, you can say: “HMR was already supported” but hey, it’s now much easier than before. In fact, now you can enable HMR by using a simple flag.

ng serve --hmr

After the local server is started, the console will print the following message:

“NOTICE: Hot Module Replacement (HMR) is enabled for the dev server.”

Faster

I know, I know. You’ve already heard this word… “faster” … others millions of times. But the Google team is working hard for making a compiler super performing and now, with this new version, the cherry on the cake is that the Angular compiler is 4x faster than before.

What does it mean?

Simple: less time waiting for builds

In details

Faster update process when installing dependencies;

Faster compilation with TypeScript v4.0;

Faster FCP (First Contentful Paint) than the Angular CLI, during the compile time, will download and inline fonts that are being used and linked in the application.

How to update to the new version?

It’s very simple and just like the other times, the Angular team suggests upgrading one major release at a time by consulting their update guide.

ng update @angular/cli @angular/core

All you have to do now is trying this new version and enjoy it! 🥳