Le novità di Angular 13 e del suo ecosistema
È 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"
}
}
...
}
Contenuti dell'articolo
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Evitare il flickering dei componenti nel prerender di Blazor 8
Gestire i null nelle reactive form tipizzate di Angular
Ottimizzare il mapping di liste di tipi semplici con Entity Framework Core
Utilizzare la libreria Benchmark.NET per misurare le performance
Eseguire attività pianificate con Azure Container Jobs
Utilizzare i primary constructor in C#
Generare file PDF da Blazor WebAssembly con iText
Evitare la script injection nelle GitHub Actions
Migrare una service connection a workload identity federation in Azure DevOps
Usare lo spread operator con i collection initializer in C#
Utilizzare un service principal per accedere a Azure Container Registry
Eseguire operazioni con timeout in React
Top Ten Articoli
- Blazor e il pattern Model-View-ViewModel
di Giampaolo Tucci - Le novità in ASP.NET Core e Blazor con .NET 7
di Morgan Pizzini - Realizzare una Progressive Web Application con Blazor e ASP.NET Core
di Giampaolo Tucci - Gestire le chiamate a servizi esterni in ASP.NET Core e Blazor tramite Polly
di Morgan Pizzini - Creare API GraphQL con ASP.NET Core e HotChocolate
di Moreno Gentili - Usare gRPC come infrastruttura per i nostri servizi web
di Morgan Pizzini - Introduzione a Blazor WebAssembly
di Marco De Sanctis, Moreno Gentili - Utilizzare scene 3D in Windows Presentation Foundation
di Marco Leoncini - Abilitare e gestire il prerendering nelle applicazioni Blazor WebAssembly
di Marco De Sanctis - Le novità di ASP.NET Core 5
di Marco De Sanctis
Articoli via e-mail
Iscriviti alla nostra newsletter nuoviarticoli per ricevere via e-mail le notifiche!
In primo piano
I più letti di oggi
- C# 4
- Spaziatura tra i caratteri in Silverlight 5
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- Segui in tempo reale il TechEd 2004
- da oggi è possibile fare login velocemente con LinkedIn e Google. a questi si aggiunge il supporto già attivo per Facebook, Twitter, Microsoft Account, Windows Hello e OpenID, per darvi sempre più possibilità di accedere semplicemente alla nostra community! #aspitalia
- Migrare una service connection a workload identity federation in Azure DevOps
- Evitare postback multipli in un UpdatePanel
In evidenza
- Ottimizzare le performance delle collection con le classi FrozenSet e FrozenDictionary
- Disabilitare automaticamente un workflow di GitHub (parte 2)
- Ottimizzazione dei block template in Angular 17
- Utilizzare il trigger SQL con le Azure Function
- Paginare i risultati con QuickGrid in Blazor
- Come EF 8 ha ottimizzato le query che usano il metodo Contains
- Evitare (o ridurre) il repo-jacking sulle GitHub Actions
- Definire stili a livello di libreria in Angular