{"id":27050,"date":"2020-04-08T00:00:00","date_gmt":"2020-04-07T22:00:00","guid":{"rendered":"https:\/\/blexin.com\/?p=27050"},"modified":"2021-01-13T09:40:08","modified_gmt":"2021-01-13T08:40:08","slug":"angular-9-cosa-cambia-e-perche-usarlo","status":"publish","type":"post","link":"https:\/\/blexin.com\/it\/blog\/angular-9-cosa-cambia-e-perche-usarlo\/","title":{"rendered":"Angular 9: cosa cambia e perch\u00e9 usarlo"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

Sappiamo che, nel nostro lavoro, il continuo aggiornamento dei framework e strumenti di sviluppo \u00e8 fonte di gioie e dolori. In questo articolo, vedremo quali sono le novit\u00e0 di Angular 9, perch\u00e9 \u00e8 una versione importante e quanto valga la pena provarla subito.<\/p>\n\n\n\n

La pubblicazione della versione 9 era prevista per Novembre 2019, ma l\u2019annuncio ufficiale di Stephen Fluin<\/a> \u00e8 arrivato solo il 6 Febbraio. Ci\u00f2 ha suscitato molte critiche dovute al fatto che il team di Angular porta con s\u00e9 una naturale diffidenza, erede di quella transizione drammatica<\/em> da Angular.js alla versione 2.0.<\/p>\n\n\n\n

Prima di entrare nel dettaglio, vi segnalo che il 26 Marzo \u00e8 stata pubblicata anche la versione 9.1 che utilizzer\u00f2 in questo articolo.<\/p>\n\n\n\n

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

Ci rendiamo conto dell\u2019importanza della versione 9 quando scopriamo che introduce per default Ivy, <\/strong>una nuova pipeline di compilazione e rendering (disponibile per esperimenti gi\u00e0 dalla versione 8).<\/p>\n\n\n\n

Perch\u00e9 questa riscrittura? Prima di tutto, il traffico web proviene in gran parte da smartphone e tablet. La sfida dei programmatori front-end \u00e8 quella di caricare un\u2019applicazione web il pi\u00f9 velocemente possibile, considerando l\u2019instabilit\u00e0 delle connessioni internet a nostra disposizione. Il primo passo \u00e8 ridurre la dimensione del bundle prodotto dal framework, e Ivy raggiunge questo risultato generando meno codice per ciascun componente e utilizzando un algoritmo chiamato tree-shaking<\/a> che rimuove le sezioni di Angular inutilizzate. I risultati sono importanti per applicazioni piccole e grandi mentre quelle di dimensione media non hanno ancora riduzioni sensibili.<\/p>\n\n\n\n

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

Nuova esperienza di Debug<\/strong><\/h2>\n\n\n\n

Creiamo un nuovo progetto utilizzando il comando ng new che si arricchisce di una opzione –minimal che rimuove tutti i file necessari per il testing.<\/p>\n\n\n\n

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

Immaginiamo di avere un componente padre chiamato ProductListComponent e un componente figlio chiamato ProductDetails. A partire da questa situazione, vediamo come cambia l\u2019esperienza di debug in Angular sfruttando i developer tool di Chrome.<\/p>\n\n\n\n

Selezioniamo nel panel components il nostro componente padre e spostiamoci nella console.<\/p>\n\n\n\n

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

Dalla console possiamo accedere a un nuovo oggetto chiamato ng<\/strong><\/a>, <\/strong>pensato per migliorare l\u2019esperienza di debug. Partiamo associando a una variabile l\u2019elemento selezionato disponibile mediante l\u2019alias $0. Le api di ng restituiscono il componente mediante ng.getContext($0).<\/p>\n\n\n\n

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

Possiamo clonare il primo prodotto, modificarlo e visualizzare le differenze con un console.table<\/p>\n\n\n\n

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

e, infine, invocare ng.applyChanges($0) per eseguire la change detection<\/strong> in Angular. Volendo, possiamo invocare anche i metodi del componente selezionato, per simulare la pressione di un bottone.<\/p>\n\n\n\n

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

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

Typescript permette di identificare i type error<\/em> nel codice ma finora mancava un supporto altrettanto forte nella parte di templating. Esiste, all\u2019interno del file tsconfig.json, un flag chiamato fullTemplateTypeCheck che, nella versione 9 di Angular, \u00e8 impostato a true. Il valore false di tale flag provoca il cosiddetto basic <\/em>type-checking mode<\/strong>. Consideriamo il caso seguente:<\/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
Il compilatore controlla che:<\/p>\n\n\n\n
  1. user sia una property della classe component<\/li>
  2. user sia un oggetto con una propriet\u00e0 address<\/li>
  3. user.address sia un oggetto con una propriet\u00e0 city<\/li><\/ol>\n\n\n\n
    Nel basic type-checking mode, il compilatore non verifica che il valore di user.address.city sia assegnabile alla input store del componente figlio. Inoltre, non vengono controllate le cosiddette embedded view<\/strong>, ad esempio *ngIf, *ngFor e gli ng-template. Non vengono neppure controllati i risultati delle pipe e i tipi di $event negli event binding.<\/p>\n\n\n\n
    Quando il flag fullTemplateTypeCheck \u00e8 uguale a true, Angular esegue un type checking pi\u00f9 rigoroso. Le embedded view vengono controllate, le pipe hanno il corretto tipo di ritorno e tutte le reference locali alle direttive e pipe hanno il tipo corretto.<\/p>\n\n\n\n
    Prendiamo ad esempio il caso di un *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> e <span> non vengono controllati. In modalit\u00e0 full, invece, il compilatore controlla che config e user esistano ma assume un tipo any per esse!<\/p>\n\n\n\n
    Angular 9 introduce una terza modalit\u00e0 di controllo, chiamata strict mode<\/strong>. Con essa il framework determina che user nello span \u00e8 di un tipo User e che address \u00e8 un oggetto con una propriet\u00e0 city di tipo string.<\/p>\n\n\n\n
    Lo strict mode \u00e8 accessibile solo con Ivy settando tsconfig.json nel modo seguente<\/p>\n\n\n
    \n"angularCompilerOptions":\n{\n    "strictTemplates": true,\n    "strictInjectionParameters": true\n}\n<\/pre><\/div>\n\n\n
    Consideriamo il seguente esempio:<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    Ho intenzionalmente cambiato il case della propriet\u00e0 id che nella definizione dell\u2019interfaccia \u00e8 invece id. Lasciando il tsconfig.json nella versione originaria<\/p>\n\n\n
    \n"angularCompilerOptions": \n{\n    "fullTemplateTypeCheck": true,\n    "strictInjectionParameters": true\n}\n<\/pre><\/div>\n\n\n
    la compilazione mediante comando ng build viene superata con successo.<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    Passando invece in strict mode, la compilazione fallisce.<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    La compilazione AOT<\/strong><\/h2>\n\n\n\n
    Abituati a lanciare le nostre app con il comando ng serve, quante volte ci siamo trovati di fronte ad errori di compilazione al momento di andare in produzione eseguendo il comando ng build –prod? Quello che succedeva era che con quest\u2019ultima opzione veniva avviata la compilazione AOT (Ahead-Of-Time).<\/p>\n\n\n\n
    Ma perch\u00e9 abbiamo bisogno di una compilazione? Cosa viene compilato? Quando avviene? Il compilatore Angular pu\u00f2 essere invocato a runtime (ossia nel browser dell\u2019utente) o a build-time nel processo di build. Si \u00e8 sempre parlato, infatti, della portabilit\u00e0 di Angular, ossia del fatto che il framework possa essere eseguito su qualsiasi piattaforma con una VM Javascript.<\/p>\n\n\n\n
    Nel primo caso (Just-In-Time Compilation) il flusso tipico \u00e8:<\/p>\n\n\n\n