Le novità di Angular 13 e del suo ecosistema

di Morgan Pizzini, in Angular,

È oramai consuetudine attendersi due rilasci annuali per Angular e anche quest'anno, il 3 Novembre 2021, è stata rilasciata la versione 13. In questo articolo cerchiamo di capire quali sono i vantaggi portati da questa nuova major release e se vale la pena aggiornare, perchè, come sappiamo, un'applicazione basata su un framework frontend JavaScript può essere ricca di librerie e a volte l'aggiornamento potrebbe portare a qualche problema.

Iniziamo dicendo che questo aggiornamento segna un punto importante nella storia di Angular. Se infatti gli ultimi sono passati quasi in sordina, portanto solo piccole novità o miglioramenti, oggi assistiamo a un completo cambio di rotta: viene abbandonato il View Engine, cioè il sistema che, prima del rilascio di Ivy, a cavallo tra la versione 8 e 9, gestiva lo stato della pagina durante il runtime. Questa scelta consente di scrollarsi dalle spalle numerose funzionalità che permettevano la coesistenza di tali sistemi e ottenere un netto miglioramento in termini di performance.

Ma non è tutto, assistiamo anche all'aggiornamento a RxJS 7.4, la libreria che consente di scrivere codice reactive, in grado cioè di eseguirsi in seguito a una callback o in risposta ad un metodo asincrono.

La scelta di abbandonare il view Engine ha favorito anche l'ecosistema di librerie che ruota attorno ad Angular, prendiamo come esempio generale NgRX e le sue nuove implementazioni rese possibili grazie all'adozione generale di Ivy.

Addio View Engine

Da Angular 9 è stata data ufficialmente la possibilità di eseguire build utilizzando il nuovo compilatore Ivy, il che porta a un problema di retrocompatibilità con le librerie esterne, dovuto alla differenza di pacchetto prodotto. Per questo motivo è stato ideato ngcc ( Angualr compatibility compiler), il quale, come dice il nome, riesce a utilizzare librerie compilate con View Engine all'interno di Ivy.

Questo prodotto era necessario in quanto il View Engine ha un meccanismo di aggiornamento della pagina basato sui cambiamenti e un interprete: dopo aver costruito il DOM della pagina, e creato tutti i binding, il lavoro del View Engine consiste nel controllare il cambiamento degli elementi, cioè gestire la "change detection". A seguito di un'interazione dell'utente, il componente viene segnalato come "da aggiornare", attraverso la proprietà "isChanged", e un interprete si prenderà carico di sincronizzare il DOM adeguatamente. Con Ivy questa procedura è ridotta al minimo: alla rilevazione della modifica verranno immediatamente create delle istruzioni che permetteranno di aggiornare il DOM, senza dover passare delle informazioni all'interprete.

Ora che, con la versione 13, il View Engine è stato completamente abbandonato, non vi è più la necessità di includere ngcc con i relativi metadata e file di contesto, rendendo tutto il processo di sviluppo e rilascio molto più veloce.

Anche la compilazione delle librerie è stata snellita, aggiornando Angular Package Format (APF) all'ultima versione JavaScript (ES2020), rimuovendo tutti i formati che si basavano su ngcc, rendendo il pacchetto nettamente più leggero e aggiungendo il supporto all'esportazione di pacchetti utilizzando lo standard Node.

Ma cosa comporta questo cambiamento per noi sviluppatori? Teoricamente nulla, perchè sono tutte modifiche effettuate dietro le quinte; il fatto che Ivy sia disponibile già da 4 versioni ci fa ben sperare che anche i creatori di librerie siano passati a questa tecnologia da tempo.

Alla migrazione dalla versione 12 alla 13, potremmo però trovare qualche piccola breaking change, dovuta alla rimozione di ngcc. Nell'esempio seguente vediamo come un set di istruzioni, che faceva uso di uno strumento intermedio per gestire la coesistenza View Engine/Ivy, ora potrà essere riscritto aumentandone la leggibilità.

@Directive({ … })
// Prima
export class MyDirective {
    constructor(private viewContainerRef: ViewContainerRef,
                private componentFactoryResolver: ComponentFactoryResolver) {}

    createMyComponent() {
        // factory method per gestire VE/Ivy
        const componentFactory = this.componentFactoryResolver.
                             resolveComponentFactory(MyComponent);
    
        this.viewContainerRef.createComponent(componentFactory);
    }
}

// Dopo
@Directive({ … })
export class MyDirective {
    constructor(private viewContainerRef: ViewContainerRef) {}
    createMyComponent() {
        // creazione diretta del componente
        this.viewContainerRef.createComponent(MyComponent);
    }
}

Addio IE11

A seguito di varie richieste provenienti dalla community, è stato ufficialmente abbandonato il supporto a Internet Explorer 11, non vi sarà più la necessità di creare polyfills e di conseguenza tutte le procedure per il differential loading: quella pratica che permetteva di caricare specifici assets in presenza di IE. A questo si somma la possibilità di implementare all'interno di Angular tutte le novità moderne che i nuovi browser supportano, come le variabili, proprietà logiche, metodi CSS e le web animation.

È finalmente possibile creare delle CSS custom properties per controllare lo stile della nostra applicazione, o di un componente, senza dover ricorrere a CSS override o ad ::ng-deep, un costrutto che permette in fase di compilazione di estendere l'area di competenza di alcuni stili CSS. Nella sezione seguente vediamo come sia facile impostare uno stile di default per un paragrafo ed eseguirne l'override dove richiesto.

:root {
  --txt-color: black;
  --bg-color: white;
}
p.paragraph {
  color: var(--txt-color);
  background-color: var(--bg-color);
}

/* override */
:root {
  --txt-color: white;
  --bg-color: black;
}

Per tutte le applicazioni che richiedono l'esecuzione su IE si consiglia di non aggiornare, in quanto lanciando il comando ng update, lo script cancellerà tutto quello che non è più richiesto. Il supporto ad Angular 12 è comunque garantito fino a Novembre 2022.

Miglioramenti nei tempi di build

Un ulteriore novità è l'utilizzo della persistence build cache: una catella dove verranno persistite tutte le informazioni riguardanti il processo di build, per poter essere riutilizzate a una successiva compilazione. Stando alle statistiche questa procedura permette di migliorare i tempi di build fino al 68%. Il tutto va a contorno dell'utilizzo di esbuild con il parser terser in grado di, oltre a ottimizzare gli script, lavorare anche sul CSS, garantendo il pacchetto più piccolo possibile.

Ogni nuovo progetto verrà pre-impostato per garantire una persistence build cache, mentre per abilitarla su un progetto esistente, provenendo dalla versione 12, dobbiamo inserire poche righe all'interno del file angular.json

{
    "$schema": "...",
    "cli": {
        "cache": {
            "enabled": true,
            "path": ".cache",
            "environment": "all"
        }
    }
    ...
}
2 pagine in totale: 1 2
Contenuti dell'articolo

Commenti

Visualizza/aggiungi commenti

| Condividi su: Twitter, Facebook, LinkedIn

Per inserire un commento, devi avere un account.

Fai il login e torna a questa pagina, oppure registrati alla nostra community.

Approfondimenti