Il y a six mois, nous avons franchi une étape importante dans la simplicité d'Angular et l'expérience des développeurs en sortant les API autonomes de l'aperçu pour développeurs. Aujourd'hui, nous sommes ravis de partager la poursuite de l'élan Angular avec la plus grande version depuis le déploiement initial d'Angular, faisant des bonds importants dans la réactivité, le rendu côté serveur et l'outillage. Tout cela s'accompagne de dizaines d'améliorations de la qualité de vie à travers les demandes de fonctionnalités, avec plus de 2 500 pouces combinés sur GitHub !
Repenser la réactivité
Dans le cadre de la version 16, nous sommes ravis de partager avec les développeurs un tout nouveau modèle de réactivité pour Angular, qui apporte des améliorations significatives aux performances et à l'expérience des développeurs.
Il est entièrement rétrocompatible et interopérable avec le système actuel, et permet :
- De meilleures performances d'exécution en réduisant le nombre de calculs lors de la détection des changements. Une fois qu'Angular Signals sera complètement déployé, nous nous attendons à des améliorations significatives de la métrique INP Core Web Vital pour les applications construites avec Signals.
- Apporte un modèle mental plus simple pour la réactivité, en clarifiant les dépendances de la vue et le flux de données à travers l'application.
- Permet une réactivité fine, qui dans les prochaines versions nous permettra de vérifier les changements uniquement dans les composants concernés.
- Rend Zone.js optionnel dans les prochaines versions en utilisant des signaux pour notifier le framework lorsque le modèle a changé
- Fournit des propriétés calculées sans la pénalité de recalcul à chaque cycle de détection de changement
- Permet une meilleure interopérabilité avec RxJS en décrivant un plan pour introduire des entrées réactives.
La discussion initiale sur GitHub a reçu 682 commentaires et depuis, nous avons partagé une série de RFC ( Requests for comments, littéralement « demandes de commentaires ») qui en ont reçu plus de 1 000 !
Dans la v16, vous pouvez trouver une nouvelle bibliothèque de signaux qui fait partie de @angular/core et un package d'interopérabilité avec RxJS - @angular/core/rxjs-interop, l'intégration complète des signaux dans le framework arrivera plus tard dans l'année.
Angular Signals
La bibliothèque Angular signals vous permet de définir des valeurs réactives et d'exprimer des dépendances entre elles. Vous pouvez en savoir plus sur les propriétés de la bibliothèque dans la RFC correspondante. Voici un exemple simple d'utilisation avec Angular :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| @Component({
selector: 'my-app',
standalone: true,
template: `
{{ fullName() }} <button (click)="setName('John')">Click</button>
`,
})
export class App {
firstName = signal('Jane');
lastName = signal('Doe');
fullName = computed(() => `${this.firstName()} ${this.lastName()}`);
constructor() {
effect(() => console.log('Name changed:', this.fullName()));
}
setName(newName: string) {
this.firstName.set(newName);
} |
L'extrait ci-dessus crée une valeur calculée fullName, qui dépend des signaux firstName et lastName. Nous déclarons également un effet, dont le callback sera exécuté chaque fois que nous changerons la valeur de l'un des signaux qu'il lit - dans ce cas, fullName, ce qui signifie qu'il dépend transitivement aussi de firstName et de lastName.
Lorsque nous fixons la valeur de firstName à "John", le navigateur se connecte à la console :
Code:
"Name changed: John Doe"
Interopérabilité RxJS
Vous pourrez facilement "lever" des signaux vers des observables grâce aux fonctions de @angular/core/rxjs-interop qui est en developer preview dans le cadre de la version v16 !
Voici comment convertir un signal en observable :
Code:
1
2
3
4
5
6
7
8
9
10
11
| import { toObservable, signal } from '@angular/core/rxjs-interop';
@Component({...})
export class App {
count = signal(0);
count$ = toObservable(this.count);
ngOnInit() {
this.count$.subscribe(() => ...);
}
} |
...et voici un exemple de conversion d'un observable en signal pour éviter d'utiliser le conduit asynchrone :
Code:
1
2
3
4
5
6
7
8
9
10
11
| import {toSignal} from '@angular/core/rxjs-interop';
@Component({
template: `
<li *ngFor="let row of data()"> {{ row }} </li>
`
})
export class App {
dataService = inject(DataService);
data = toSignal(this.dataService.data$, []);
} |
Les utilisateurs d'Angular souhaitent souvent compléter un flux lorsqu'un sujet connexe se termine. L'exemple suivant est assez courant :
Code:
1
2
3
4
5
6
7
| destroyed$ = new ReplaySubject<void>(1);
data$ = http.get('...').pipe(takeUntil(this.destroyed$));
ngOnDestroy() {
this.destroyed$.next();
} |
Nous introduisons un nouvel opérateur RxJS appelé takeUntilDestroy, qui simplifie cet exemple comme suit :
Code:
data$ = http.get('…').pipe(takeUntilDestroyed());
Par défaut, cet opérateur injecte le contexte de nettoyage actuel. Par exemple, utilisé dans un composant, il utilisera la durée de vie du composant.
takeUntilDestroy est particulièrement utile lorsque vous souhaitez lier le cycle de vie d'un Observable au cycle de vie d'un composant particulier.
Prochaines étapes pour les signaux
Nous allons maintenant travailler sur les composants basés sur les signaux, qui disposent d'un ensemble simplifié de crochets de cycle de vie et d'une autre façon, plus simple, de déclarer les entrées et les sorties. Nous travaillerons également sur un ensemble plus complet d'exemples et de documentation.
L'un des problèmes les plus populaires dans le référentiel Angular est "Proposal : Input as Observable". Il y a quelques mois, nous avons répondu que nous voulions soutenir ce cas d'utilisation dans le cadre d'un effort plus important dans le framework. Nous sommes heureux de partager que plus tard cette année, nous allons lancer une fonctionnalité qui permettra des entrées basées sur des signaux - vous serez en mesure de transformer les entrées en observables via le paquet interop !
Rendu côté serveur et hydratation améliorés
D'après notre enquête annuelle auprès des développeurs, le rendu côté serveur est la principale opportunité d'amélioration pour Angular. Au cours des deux derniers mois, nous avons collaboré avec l'équipe Chrome Aurora pour améliorer les performances et le DX de l'hydratation et du rendu côté serveur. Aujourd'hui, nous sommes heureux de partager l'aperçu développeur de l'hydratation non destructive de l'application complète !
Dans la nouvelle hydratation non-destructive de l'application complète, Angular ne redessine plus l'application à partir de zéro. Au lieu de cela, le framework recherche les nœuds DOM existants tout en construisant des structures de données internes et attache des récepteurs d'événements à ces nœuds.
Les avantages sont les suivants :
- Pas de contenu vacillant sur une page pour les utilisateurs finaux
- Amélioration de Web Core Vitals dans certains scénarios
- Une architecture à l'épreuve du temps qui permet un chargement de code fin avec des primitives que nous livrerons plus tard dans l'année. Actuellement, cela se traduit par une hydratation progressive des routes paresseuses.
- Intégration facile avec les applications existantes, en seulement quelques lignes de code (voir l'extrait de code ci-dessous)
- Adoption progressive de l'hydratation avec l'attribut ngSkipHydration dans les templates pour les composants effectuant une manipulation manuelle du DOM.
Lors des premiers tests, nous avons constaté une amélioration de 45% de la plus grande peinture Contentful avec une hydratation complète de l'application !
Certaines applications ont déjà activé l'hydratation en production et ont rapporté des améliorations CWV :
Pour commencer, il suffit d'ajouter quelques lignes à votre fichier main.ts :
Code:
1
2
3
4
5
6
7
8
9
10
| import {
bootstrapApplication,
provideClientHydration,
} from '@angular/platform-browser';
...
bootstrapApplication(RootCmp, {
providers: [provideClientHydration()]
}); |
Nouvelles fonctionnalités de rendu côté serveur
Dans le cadre de la version 16, nous avons également mis à jour les schémas ng add pour Angular Universal, ce qui vous permet d'ajouter le rendu côté serveur aux projets utilisant des API autonomes. Nous avons également introduit la prise en charge d'une politique de sécurité du contenu plus stricte pour les styles en ligne.
Prochaines étapes de l'hydratation et du rendu côté serveur
Nous avons encore beaucoup à faire dans ce domaine et le travail effectué dans la v16 n'est qu'un tremplin. Dans certains cas, il est possible de retarder le chargement du JavaScript qui n'est pas essentiel pour la page et d'hydrater les composants associés plus tard. Cette technique est connue sous le nom d'hydratation partielle et nous l'explorerons par la suite.
Depuis que Qwik a popularisé l'idée de la resumabilité à partir du framework fermé Wiz de Google, nous avons reçu de nombreuses demandes pour cette fonctionnalité dans Angular. La resumabilité est définitivement sur notre radar, et nous travaillons en étroite collaboration avec l'équipe Wiz pour explorer cet espace. Nous sommes prudents quant aux contraintes qui pèsent sur l'expérience des développeurs, nous évaluons les différents compromis et nous vous tiendrons au courant de nos progrès.
Vous pouvez en savoir plus sur nos plans futurs dans "What's next for server-side rendering in Angular".
Amélioration de l'outillage pour les composants autonomes, les directives et les tuyaux
Angular est un framework utilisé par des millions de développeurs pour un grand nombre d'applications critiques et nous prenons les changements majeurs au sérieux. Nous avons commencé à explorer les API autonomes il y a des années, en 2022, nous les avons publiées en version developer preview. Après plus d'un an de collecte de commentaires et d'itération sur les API, nous aimerions encourager une adoption encore plus large !
Pour aider les développeurs à faire passer leurs applications aux API autonomes, nous avons élaboré des schémas de migration et un guide de migration autonome. Une fois dans le répertoire de votre projet, exécutez :
Code:
ng generate @angular/core:standalone
Les schémas convertiront votre code, supprimeront les classes NgModules superflues et modifieront enfin l'amorce du projet pour utiliser des API autonomes.
Standalone ng new collection
Dans le cadre d'Angular v16, vous pouvez créer de nouveaux projets en tant que standalone dès le départ ! Pour essayer l'aperçu développeur des schémas autonomes, assurez-vous que vous êtes sur Angular CLI v16 et exécutez :
Code:
ng new --standalone
Vous obtiendrez un projet plus simple sans aucun NgModules. De plus, tous les générateurs du projet produiront des directives, des composants et des tuyaux autonomes !
Configurer Zone.js
Après la sortie initiale des API autonomes, des développeurs nous ont dit qu'ils aimeraient pouvoir configurer Zone.js avec la nouvelle API `bootstrapApplication`.
Nous avons ajouté une option pour cela via provideZoneChangeDetection :
Code:
1
2
3
| bootstrapApplication(App, {
providers: [provideZoneChangeDetection({ eventCoalescing: true })]
}); |
Faire progresser l'outillage des développeurs
Partageons maintenant quelques points forts de l'interface de programmation Angular et du service linguistique.
Aperçu pour les développeurs du système de construction basé sur esbuild
Il y a plus d'un an, nous avons annoncé que nous travaillions sur la prise en charge expérimentale d'esbuild dans l'interface de gestion d'Angular afin d'accélérer vos constructions. Aujourd'hui, nous sommes ravis de partager que dans la v16, notre système de construction basé sur esbuild entre dans l'aperçu pour les développeurs ! Les premiers tests ont montré une amélioration de 72 % dans les builds de production à froid.
Dans ng serve, nous utilisons maintenant Vite pour le serveur de développement, et esbuild alimente à la fois vos builds de développement et de production !
Nous tenons à souligner qu'Angular CLI s'appuie exclusivement sur Vite en tant que serveur de développement. Pour supporter la correspondance des sélecteurs, le compilateur Angular doit maintenir un graphe de dépendance entre vos composants, ce qui nécessite un modèle de compilation différent de celui de Vite.
Vous pouvez essayer Vite + esbuild en mettant à jour votre angular.json :
Code:
1
2
3
4
5
| ...
"architect": {
"build": { /* Add the esbuild suffix */
"builder": "@angular-devkit/build-angular:browser-esbuild",
... |
Ensuite, nous nous attaquerons à la prise en charge de l'i18n avant de sortir ce projet de l'aperçu pour développeurs.
De meilleurs tests unitaires avec Jest et Web Test Runner
D'après les enquêtes menées auprès des développeurs d'Angular et de la communauté JavaScript au sens large, Jest est l'un des frameworks de test et des runners de test les plus appréciés. Nous avons reçu de nombreuses demandes de prise en charge de Jest, qui s'accompagne d'une complexité réduite puisqu'aucun navigateur réel n'est requis.
Aujourd'hui, nous sommes heureux d'annoncer que nous introduisons le support expérimental de Jest. Dans une prochaine version, nous déplacerons également les projets Karma existants vers Web Test Runner pour continuer à supporter les tests unitaires basés sur le navigateur. Pour la majorité des développeurs, il n'y aura pas de problème.
Vous pouvez expérimenter Jest dans de nouveaux projets en installant Jest avec npm install jest --save-dev et en mettant à jour votre fichier angular.json :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| {
"projects": {
"my-app": {
"architect": {
"test": {
"builder": "@angular-devkit/build-angular:jest",
"options": {
"tsConfig": "tsconfig.spec.json",
"polyfills": ["zone.js", "zone.js/testing"]
}
}
}
}
}
} |
Autocomplétion des importations dans les modèles
Combien de fois avez-vous utilisé un composant ou un tuyau dans un modèle pour obtenir une erreur de la part de l'interface de programmation ou du service de langue, vous indiquant que vous n'avez pas importé l'implémentation correspondante ? Je parie qu'il y en a des tonnes !
Le service linguistique permet désormais l'importation automatique de composants et de tuyaux.
Gif montrant la fonctionnalité d'auto-importation du service de langue Angular dans VSCode
Et ce n'est pas tout !
Dans la v16, nous activons également la prise en charge de TypeScript 5.0, avec la prise en charge des décorateurs ECMAScript, la suppression de la surcharge de ngcc, l'ajout de la prise en charge des travailleurs de service et de l'app shell dans les applications autonomes, l'extension de la prise en charge de CSP dans la CLI, et bien plus encore !
Améliorer l'expérience des développeurs
En plus des grandes initiatives sur lesquelles nous nous concentrons, nous travaillons également à apporter des fonctionnalités très demandées.
Entrées requises
Depuis que nous avons introduit Angular en 2016, il n'a pas été possible d'obtenir une erreur de compilation si vous ne spécifiez pas une valeur pour une entrée spécifique. Le changement n'ajoute aucune surcharge à l'exécution puisque le compilateur Angular effectue la vérification au moment de la construction. Les développeurs n'ont cessé de demander cette fonctionnalité au fil des ans et nous avons reçu une forte indication que cela sera très pratique !
Dans la v16, vous pouvez maintenant marquer une entrée comme requise :
Code:
1
2
3
4
| @Component(...)
export class App {
@Input({ required: true }) title: string = '';
} |
Transmission des données du routeur en tant qu'entrées de composants
L'expérience des développeurs du routeur a progressé rapidement. Une demande de fonctionnalité populaire sur GitHub demande la possibilité de lier les paramètres de la route aux entrées du composant correspondant. Nous sommes heureux de vous annoncer que cette fonctionnalité est désormais disponible dans le cadre de la version 16 !
Vous pouvez désormais passer les données suivantes aux entrées d'un composant de routage :
- Données de l'itinéraire - résolveurs et propriétés des données
- Paramètres du chemin
- Paramètres de requête
Voici un exemple de la façon dont vous pouvez accéder aux données d'un résolveur d'itinéraires :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
| const routes = [
{
path: 'about',
loadComponent: import('./about'),
resolve: { contact: () => getContact() }
}
];
@Component(...)
export class About {
// The value of "contact" is passed to the contact input
@Input() contact?: string;
} |
Prise en charge de la CSP pour les styles en ligne
Les éléments de style en ligne qu'Angular inclut dans le DOM pour les styles de composants violent la politique de sécurité du contenu par défaut style-src (CSP). Pour corriger cela, ils devraient soit contenir un attribut nonce, soit le serveur devrait inclure un hachage du contenu du style dans l'en-tête CSP. Même si Google n'a pas trouvé de vecteur d'attaque significatif pour cette vulnérabilité, de nombreuses entreprises appliquent une CSP stricte, ce qui a conduit à la popularité d'une demande de fonctionnalité sur le référentiel Angular.
Dans Angular v16, nous avons implémenté une nouvelle fonctionnalité couvrant le framework, Universal, CDK, Material, et le CLI qui vous permet de spécifier un attribut nonce pour les styles des composants qu'Angular inline. Il y a deux façons de spécifier le nonce : en utilisant l'attribut ngCspNonce ou à travers le jeton d'injection CSP_NONCE.
L'attribut ngCspNonce est utile si vous avez accès à un modèle côté serveur qui peut ajouter le nonce à la fois à l'en-tête et à l'index.html lors de la construction de la réponse.
Code:
1
2
3
4
5
| <html>
<body>
<app ngCspNonce="{% nonce %}"></app>
</body>
</html> |
L'autre façon de spécifier le nonce est d'utiliser le jeton d'injection CSP_NONCE. Utilisez cette approche si vous avez accès à nonce au moment de l'exécution et que vous voulez pouvoir mettre en cache le fichier index.html :
Code:
1
2
3
4
5
6
7
8
9
| import {bootstrapApplication, CSP_NONCE} from '@angular/core';
import {AppComponent} from './app/app.component';
bootstrapApplication(AppComponent, {
providers: [{
provide: CSP_NONCE,
useValue: globalThis.myRandomNonceValue
}]
}); |
Flexible ngOnDestroy
Les crochets de cycle de vie d'Angular fournissent beaucoup de puissance pour se brancher sur différents moments de l'exécution de votre application. Au fil des ans, il a été possible d'offrir une plus grande flexibilité, par exemple en donnant accès à OnDestroy en tant qu'observable.
Dans la v16, nous avons rendu OnDestroy injectable, ce qui permet la flexibilité que les développeurs demandaient. Cette nouvelle fonctionnalité vous permet d'injecter DestroyRef correspondant à un composant, une directive, un service ou un tuyau - et d'enregistrer le crochet du cycle de vie de OnDestroy. Le DestroyRef peut être injecté n'importe où dans un contexte d'injection, y compris à l'extérieur de votre composant - dans ce cas, le hook onDestroy est exécuté lorsqu'un injecteur correspondant est détruit. :
Code:
1
2
3
4
5
6
7
8
9
10
| import { Injectable, DestroyRef } from '@angular/core';
@Injectable(...)
export class AppService {
destroyRef = inject(DestroyRef);
destroy() {
this.destroyRef.onDestroy(() => /* cleanup */ );
}
} |
Balises auto-fermantes
Une fonctionnalité très demandée que nous avons récemment mise en œuvre vous permet d'utiliser des balises de fermeture automatique pour les composants dans les modèles Angular. Il s'agit d'une petite amélioration de l'expérience du développeur qui pourrait vous faire économiser de la frappe !
Vous pouvez désormais remplacer :
Code:
<super-duper-long-component-name [prop]="someVar"></super-duper-long-component-name>
avec ceci :
Code:
<super-duper-long-component-name [prop]="someVar"/>
Des composants meilleurs et plus flexibles
Au cours des deux derniers trimestres, nous avons travaillé en étroite collaboration avec l'équipe Material Design de Google pour fournir l'implémentation de référence de Material 3 pour le Web avec Angular Material. Les composants Web MDC que nous avons livrés en 2022 ont jeté les bases de cet effort.
La prochaine étape consistera à lancer plus tard dans l'année une API de thématisation expressive basée sur des jetons qui permettra une personnalisation plus poussée des composants matériels d'Angular.
Nous vous rappelons que nous supprimerons les anciens composants non basés sur le MDC dans la v17. Assurez-vous de suivre notre guide de migration pour passer à la dernière version.
Poursuite de notre initiative en matière d'accessibilité
Conformément à la mission de Google, Angular vous permet de construire des applications web pour tout le monde ! C'est pourquoi nous investissons continuellement dans l'amélioration de l'accessibilité du CDK Angular et des composants Material.
Points forts de la contribution de la communauté
Deux des fonctionnalités introduites par la communauté que nous souhaitons mettre en avant sont :
- Les diagnostics étendus pour une utilisation correcte de ngSkipHydration par Matthieu Riegler.
- L'introduction de provideServiceWorker pour permettre l'utilisation du service worker d'Angular sans NgModules par Julien Saguet.
Plus de 175 personnes ont contribué à la v16 sur GitHub et des milliers d'autres ont contribué via des articles de blog, des conférences, des podcasts, des vidéos, des commentaires sur les RFC de réactivité, etc.
Nous tenons à remercier chaleureusement tous ceux qui nous ont aidés à rendre cette version spéciale.
Continuons ensemble sur notre lancée !
La version 16 est un tremplin pour les améliorations futures de la réactivité et du rendu côté serveur d'Angular au cours de l'année prochaine. Nous allons faire avancer le Web en innovant dans l'expérience des développeurs, la performance, tout en vous permettant de construire pour tout le monde !
Vous pouvez faire partie de l'élan Angular et nous aider à façonner l'avenir du framework en partageant vos idées dans les RFC à venir, les sondages ou les médias sociaux.
Merci de faire partie de la communauté Angular. Nous avons hâte que vous essayiez ces fonctionnalités !
