{"id":27089,"date":"2020-04-08T00:00:00","date_gmt":"2020-04-07T22:00:00","guid":{"rendered":"https:\/\/blexin.com\/angular-9-cosa-cambia-e-perche-usarlo\/"},"modified":"2021-05-20T18:28:07","modified_gmt":"2021-05-20T16:28:07","slug":"angular-9-what-changes-and-why-use-it","status":"publish","type":"post","link":"https:\/\/blexin.com\/en\/blog-en\/angular-9-what-changes-and-why-use-it\/","title":{"rendered":"Angular 9: what changes and why use it"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

In our job, it\u2019s very challenging to follow the continuous evolution of the frameworks and development tools. In this article, we will see what\u2019s new in Angular 9, why it is a remarkable version, and why it is worthful test it as soon as possible.<\/p>\n\n\n\n

The expected release date for the ninth version was November 2019, but the official announcement by Stephen Fluin<\/a> arrived only on February 6th. There were a lot of criticisms, maybe due to the natural diffidence around the Angular team, heir of that dramatic transitioning from Angular.js to version 2.0.<\/p>\n\n\n\n

Before going into the details, please note that in this article I will use version 9.1, published on March 26th.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Version 9 is relevant because it introduces, by default, Ivy<\/strong>, a new pipeline for compilation and rendering (available for testing also in version 8).<\/p>\n\n\n\n

Why this rewriting? First of all, a big part of web traffic comes from smartphones and tablets. The main challenge for a front developer is to load a web application as fast as possible, taking into account the volatility of an internet connection. The first step is to reduce the bundle size produced by the framework. The Ivy compiler has been designed to remove parts of Angular that aren\u2019t being used via tree-shaking<\/a> and to generate less code for each Angular component. Small apps and large apps can see the most dramatic size savings while medium-sized apps should see bundle sizes that are only slightly smaller.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The new Debug experience<\/strong><\/h2>\n\n\n\n

Let\u2019s create a new project using the ng new command and the –minimal option that removes all the files necessary for the testing.<\/p>\n\n\n\n

ng new my-first-demo--minimal --style=css<\/code><\/p>\n\n\n\n

Let us suppose to have a father component called ProductListComponent and its son called ProductDetails. Starting from this situation, let\u2019s see how the debug experience in Angular changes using the Chrome developer tools. Select our father component in the Components<\/strong> panel, and let\u2019s move to the console.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Inside the console, we can access a new object called ng<\/strong><\/a>, designed to improve the debugging experience. Let\u2019s start associating a variable to the selected component, available through the $0 alias. The ng api returns the component with ng.getContext($0).<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

We can clone the first product, modify it, show the differences with a console.table<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

and, finally, invoke ng.applyChanges($0) to force the change detection<\/strong> in Angular. We can also invoke the methods of the selected component to emulate the click on a button.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Type checking<\/strong><\/h2>\n\n\n\n

Typescript allows us to find the type errors inside the code but, till now, the templating missed such strong support. Inside the tsconfig.json file, there is a flag called fullTemplateTypeCheck that in Angular 9 is set to true while the false value triggers the basic type-checking mode<\/strong>. Let\u2019s consider the following case:<\/p>\n\n\n

\n<app-product-details\n    [store]="user.address.city" [product]="selectedProduct">\n<\/app-product-details>\n<\/pre><\/div>\n\n\n
The compiler checks that:<\/p>\n\n\n\n
  1. user is a property belonging to the class component<\/li>
  2. user is an object with the address property<\/li>
  3. user.address is an object with the city property<\/li><\/ol>\n\n\n\n
    In the basic type-checking, the compiler does not verify that the value of user.address.city is assignable to the input called store inside the child component. Besides, the so-called embedded views<\/strong>, for example, *ngIf, *ngFor, and ng-templates are not checked. Either the results of pipes and the type of $event in event bindings are not checked.<\/p>\n\n\n\n
    When the fullTemplateTypeCheck flag is set to true, Angular applies a more rigorous type checking. Embedded views are checked, pipes have the correct value type and local references to directives and pipes have the correct type.<\/p>\n\n\n\n
    Let\u2019s consider an *ngFor:<\/p>\n\n\n
    \n<div *ngFor="let product of products">\n    <h3>{{config.title}}<\/h2>\n    <span>Store: {{user.address.city}}<\/span>\n<\/div>\n<\/pre><\/div>\n\n\n
    In basic mode, <h3> and <span> are not checked. In full modality, instead, the compiler checks if config and user exist, but it assumes any type for them!<\/p>\n\n\n\n
    Angular 9 introduces a third check modality called strict mode<\/strong>. With it, the framework defines that user inside the span has a User type, and that address is an object with a string property called city.<\/p>\n\n\n\n
    The strict mode is accessible only with Ivy, setting tsconfig.json like this:<\/p>\n\n\n
    \n"angularCompilerOptions":\n{\n    "strictTemplates": true,\n    "strictInjectionParameters": true\n}\n<\/pre><\/div>\n\n\n
    In the following example:<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    I intentionally changed the case for the Id property that is id in the interface definition. Leaving the tsconfig.json in the original version<\/p>\n\n\n
    \n"angularCompilerOptions": \n{\n    "fullTemplateTypeCheck": true,\n    "strictInjectionParameters": true\n}\n<\/pre><\/div>\n\n\n
    the ng build compilation successfully passes.<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    Passing to the strict mode, instead, the compilation fails.<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    AOT compilation<\/strong>
    <\/strong><\/h2>\n\n\n\n
    Used to launch our apps with the ng serve command, how many times we discovered build errors as we were ready to go to production, executing the ng build –prod command? It was happening that this last option has started the AOT (Ahead of Time)<\/p>\n\n\n\n
    Why we need a compilation? What is compiled? When does this compilation happen? We can invoke the Angular compiler at runtime (in the user browser) or at build time in the build process. It has always been said that Angular is portable: it can be executed on every platform with a Javascript VM.<\/p>\n\n\n\n
    In the first case (Just-In.Time Compilation) the typical flux is:<\/p>\n\n\n\n