Feuille de route d'Angular

Signal Forms

Les Signal Forms sont désormais stables. Cette nouvelle approche permet aux développeurs de gérer l'état des formulaires avec des signals, pour une expérience de création de formulaires ergonomique. Nous avons promu les Signal Forms en version stable et amélioré l'interopérabilité avec les reactive forms, ce qui permet aux équipes de migrer progressivement de grands formulaires à leur propre rythme.

Réactivité

Nous avons introduit de nouvelles API de signals, resource() et httpResource(), pour une gestion flexible des données asynchrones. Nous avons promu ces API en version stable pour les développeurs.

Détection de changements

Le mode zoneless étant stable et activé par défaut, nous avons défini OnPush comme stratégie de détection de changements par défaut, conformément aux bonnes pratiques actuelles. Nous avons également renommé ChangeDetectionStrategy.Default en ChangeDetectionStrategy.Eager.

Consultez la discussion de la RFC pour plus de détails.

Améliorer le HMR (Hot Module Reload)

Nous travaillons à accélérer le cycle modification/rafraîchissement en activant le remplacement de modules à chaud (hot module replacement). Dans Angular v19, nous avons livré une première prise en charge du HMR pour le CSS et les templates, et dans la v20 nous avons promu le HMR des templates en version stable. Nous continuerons à recueillir des retours pour nous assurer de répondre aux besoins des développeurs avant de marquer ce projet comme terminé.

Livrer les signals Angular

Ce projet repense le modèle de réactivité d'Angular en introduisant les signals comme primitive de réactivité. La planification initiale a donné lieu à des centaines de discussions, des échanges avec des développeurs, des sessions de retours, des études d'expérience utilisateur et une série de RFC, qui ont reçu plus de 1 000 commentaires.

Dans Angular v20, nous avons promu en version stable toutes les primitives de réactivité fondamentales, notamment signal, effect, linkedSignal, les queries basées sur les signals et les inputs.

Prendre en charge le glisser-déposer en deux dimensions

Dans le cadre de ce projet, nous avons implémenté la prise en charge de l'orientation mixte pour le glisser-déposer de l'Angular CDK. C'est l'une des fonctionnalités les plus demandées du dépôt.

Event replay avec le SSR et le prérendu

Dans la v18, nous avons introduit une fonctionnalité d'event replay lors de l'utilisation du rendu côté serveur ou du prérendu. Pour cette fonctionnalité, nous nous appuyons sur la primitive event dispatch (anciennement appelée jsaction) qui s'exécute sur Google.com.

Dans Angular v19, nous avons promu l'event replay en version stable et l'avons activé par défaut pour tous les nouveaux projets.

Étendre les possibilités de personnalisation d'Angular Material

Pour mieux personnaliser nos composants Angular Material et activer les capacités de Material 3, nous collaborerons avec l'équipe Material Design de Google pour définir des API de thèmes basées sur des tokens.

Dans la v17.2, nous avons proposé une prise en charge expérimentale d'Angular Material 3, et dans la v18 nous l'avons promue en version stable.

Introduire le chargement différé

Dans la v17, nous avons livré les vues différables en developer preview, qui offrent une API ergonomique pour le chargement différé du code. Dans la v18, nous avons activé les vues différables pour les développeurs de libraries et promu l'API en version stable.

Automatiser la migration des projets existants à rendu hybride vers esbuild et Vite

Dans la v17, nous avons livré un builder d'application basé sur Vite et esbuild, et l'avons activé par défaut pour les nouveaux projets. Il améliore jusqu'à 87 % le temps de build des projets utilisant le rendu hybride. Dans la v18, nous avons livré des schematics et un guide qui migrent les projets existants utilisant le rendu hybride vers le nouveau pipeline de build.

Faire d'Angular.dev la maison officielle des développeurs Angular

Angular.dev est le nouveau site, domaine et point d'ancrage du développement Angular. Le nouveau site contient une documentation, des tutoriels et des conseils à jour qui aideront les développeurs à construire avec les dernières fonctionnalités d'Angular.

Introduire le control flow intégré

Dans la v17, nous avons livré une version developer preview d'un nouveau control flow. Il apporte d'importantes améliorations de performances et une meilleure ergonomie pour l'écriture des templates. Nous avons aussi fourni une migration des *ngIf, *ngFor et *ngSwitch existants, que vous pouvez exécuter pour faire passer votre projet à la nouvelle implémentation. Depuis la v18, le control flow intégré est stable.

Étudier les bundlers modernes

Dans Angular v16, nous avons publié une developer preview d'un builder basé sur esbuild prenant en charge ng build et ng serve. Le serveur de développement ng serve utilise Vite et une compilation multifichier par esbuild et le compilateur Angular. Dans la v17, nous avons fait sortir l'outillage de build de la developer preview et l'avons activé par défaut pour les nouveaux projets.

Introduire des API de débogage de l'injection de dépendances

Pour améliorer les outils de débogage d'Angular et d'Angular DevTools, nous travaillerons sur des API donnant accès au runtime de l'injection de dépendances. Dans le cadre du projet, nous exposerons des méthodes de débogage qui permettent d'explorer la hiérarchie des injectors et les dépendances à travers leurs providers associés. Depuis la v17, nous avons livré une fonctionnalité qui nous permet de nous brancher sur le cycle de vie de l'injection de dépendances. Nous avons aussi lancé une visualisation de l'arbre des injectors et l'inspection des providers déclarés dans chaque injector individuel,

Améliorer la documentation et les schematics pour les composants standalone

Nous avons publié une developer preview de la collection de schematics ng new --standalone, qui vous permet de créer des applications sans NgModules. Dans la v17, nous avons fait passer le format de création des nouvelles applications aux API standalone et modifié la documentation pour refléter cette recommandation. Nous avons également livré des schematics qui permettent de migrer les applications existantes vers des composants, directives et pipes standalone. Même si les NgModules resteront présents dans un avenir prévisible, nous vous recommandons d'explorer les avantages des nouvelles API pour améliorer l'expérience de développement et profiter des nouvelles fonctionnalités que nous construisons pour elles.

Hydratation complète et non destructive des applications

Dans la v16, nous avons publié une developer preview de l'hydratation complète non destructive, qui permet à Angular de réutiliser les nœuds DOM existants d'une page rendue côté serveur au lieu de recréer une application à partir de zéro. Consultez le guide de l'hydratation pour plus d'informations.

Améliorations de la directive d'image

Nous avons publié la directive d'image d'Angular en version stable dans la v15. Nous avons introduit un nouveau mode fill qui permet aux images de s'adapter à leur conteneur parent au lieu d'avoir des dimensions explicites. Au cours des deux derniers mois, l'équipe Chrome Aurora a rétroporté la directive vers la v12 et les versions ultérieures.

Refonte de la documentation

Faire en sorte que toute la documentation existante s'inscrive dans un ensemble cohérent de types de contenus. Transformer la documentation trop orientée tutoriel en sujets indépendants. Nous voulons que le contenu en dehors des tutoriels principaux soit autonome, sans être étroitement lié à une série de guides. Au T2 2022, nous avons refondu le contenu sur les templates et l'injection de dépendances. Au T1 2023, nous avons amélioré les guides HTTP et, avec cela, nous mettons en pause le projet de refonte de la documentation.

Améliorer les performances des images

Les équipes Aurora et Angular travaillent à l'implémentation d'une directive d'image visant à améliorer les Core Web Vitals. Nous avons livré une version stable de la directive d'image dans la v15.

CSS moderne

L'écosystème web évolue constamment et nous voulons refléter les standards modernes les plus récents dans Angular. Dans ce projet, nous voulons fournir des recommandations sur l'utilisation des fonctionnalités CSS modernes dans Angular, afin que les développeurs suivent les bonnes pratiques de mise en page, de style, etc. Nous avons partagé des recommandations officielles pour la mise en page et, dans le cadre de cette initiative, avons cessé de publier flex layout.

Permettre d'ajouter des directives aux host elements

Une demande de fonctionnalité de longue date consistait à pouvoir ajouter des directives aux host elements. Cette fonctionnalité permet aux développeurs d'enrichir leurs propres composants avec des comportements supplémentaires sans utiliser l'héritage. Dans la v15, nous avons livré notre API de composition de directives, qui permet d'enrichir les host elements avec des directives.

De meilleures stack traces

Les équipes Angular et Chrome DevTools travaillent ensemble pour rendre les stack traces des messages d'erreur plus lisibles. Dans la v15, nous avons publié des stack traces plus pertinentes et liées. En tant qu'initiative de moindre priorité, nous étudierons comment rendre les stack traces plus conviviales en fournissant des noms de frames d'appel plus précis pour les templates.

Composants Angular Material améliorés grâce à l'intégration de MDC Web

MDC Web est une library créée par l'équipe Material Design de Google qui fournit des primitives réutilisables pour construire des composants Material Design. L'équipe Angular intègre ces primitives dans Angular Material. L'utilisation de MDC Web rapproche Angular Material de la spécification Material Design, étend l'accessibilité, améliore la qualité des composants et accélère le rythme de notre équipe.

Implémenter des API pour des NgModules facultatifs

Pour rendre Angular plus simple, nous travaillons à introduire des API qui permettent aux développeurs d'initialiser des applications, d'instancier des composants et d'utiliser le router sans NgModules. Angular v14 introduit en developer preview les API pour les composants, directives et pipes standalone. Au cours des prochains trimestres, nous recueillerons les retours des développeurs et finaliserons le projet en rendant les API stables. Ensuite, nous travaillerons à améliorer des cas d'usage comme TestBed, Angular Elements, etc.

Permettre le binding sur des champs protected dans les templates

Pour améliorer l'encapsulation des composants Angular, nous avons permis le binding sur les membres protected de l'instance du composant. Ainsi, vous n'aurez plus besoin d'exposer un champ ou une méthode en public pour l'utiliser dans vos templates.

Publier des guides sur les concepts avancés

Rédiger et publier un guide approfondi sur la détection de changements. Produire du contenu sur le profilage des performances des applications Angular. Expliquer comment la détection de changements interagit avec Zone.js, quand elle est déclenchée, comment profiler sa durée, ainsi que les pratiques courantes d'optimisation des performances.

Déployer le typage strict pour @angular/forms

Au T4 2021, nous avons conçu une solution pour introduire le typage strict des formulaires et, au T1 2022, nous avons clôturé la demande de commentaires (RFC) correspondante. Nous mettons actuellement en œuvre une stratégie de déploiement avec une étape de migration automatisée qui activera les améliorations pour les projets existants. Nous testons d'abord la solution sur plus de 2 500 projets chez Google pour garantir un chemin de migration fluide à la communauté externe.

Supprimer l'ancien View Engine

Une fois la transition de tout notre outillage interne vers Ivy terminée, nous supprimerons l'ancien View Engine afin de réduire la charge conceptuelle d'Angular, la taille du package, le coût de maintenance et la complexité de la base de code.

Un modèle mental d'Angular simplifié avec des NgModules facultatifs

Pour simplifier le modèle mental d'Angular et son apprentissage, nous travaillerons à rendre les NgModules facultatifs. Ce travail permet aux développeurs de développer des composants standalone et d'implémenter une API alternative pour déclarer la portée de compilation du composant. Nous avons lancé ce projet par des discussions de conception de haut niveau, que nous avons consignées dans une RFC.

Concevoir un typage strict pour @angular/forms

Nous chercherons un moyen d'implémenter une vérification de types plus stricte pour les reactive forms avec un minimum d'impacts non rétrocompatibles. Ainsi, les développeurs pourront détecter davantage de problèmes pendant le développement, bénéficier d'une meilleure prise en charge par les éditeurs de texte et les IDE, et d'une vérification de types améliorée pour les reactive forms.

Améliorer l'intégration d'Angular DevTools au framework

Pour améliorer l'intégration d'Angular DevTools au framework, nous travaillons à déplacer la base de code dans le monorepo angular/angular. Cela comprend la migration d'Angular DevTools vers Bazel et son intégration aux processus et au pipeline de CI existants.

Lancer des diagnostics avancés du compilateur

Étendre les diagnostics du compilateur Angular au-delà de la vérification de types. Introduire d'autres vérifications d'exactitude et de conformité pour mieux garantir l'exactitude du code et le respect des bonnes pratiques.

Mettre à jour notre stratégie de tests e2e

Pour proposer une stratégie de tests e2e pérenne, nous voulons évaluer l'état de Protractor, les innovations de la communauté et les bonnes pratiques e2e, et explorer de nouvelles pistes. Comme premières étapes, nous avons partagé une RFC et travaillé avec des partenaires pour assurer une intégration fluide entre l'Angular CLI et les outils de pointe pour les tests e2e. Ensuite, nous devons finaliser les recommandations et compiler une liste de ressources pour la transition.

Les libraries Angular utilisent Ivy

Début 2020, nous avons partagé une RFC sur la distribution des libraries Ivy. Après des retours précieux de la communauté, nous avons élaboré une conception du projet. Nous investissons maintenant dans le développement de la distribution des libraries Ivy, y compris une mise à jour du format de package des libraries pour utiliser la compilation Ivy, le déblocage de la dépréciation du format de library View Engine, et ngcc.

Améliorer la durée des tests et le débogage grâce au nettoyage automatique de l'environnement de test

Pour améliorer la durée des tests et mieux isoler les tests entre eux, nous voulons modifier TestBed afin qu'il nettoie et démonte automatiquement l'environnement de test après chaque exécution de test.

Déprécier et supprimer la prise en charge d'IE11

Internet Explorer 11 (IE11) empêchait Angular de tirer parti de certaines fonctionnalités modernes de la plateforme web. Dans le cadre de ce projet, nous allons déprécier puis supprimer la prise en charge d'IE11 pour ouvrir la voie aux fonctionnalités modernes qu'offrent les navigateurs evergreen. Nous avons mené une RFC pour recueillir les retours de la communauté et décider des prochaines étapes.

Utiliser ES2017+ comme langage de sortie par défaut

La prise en charge des navigateurs modernes nous permet de tirer parti de la nouvelle syntaxe JavaScript, plus compacte, plus expressive et plus performante. Dans le cadre de ce projet, nous étudierons ce qui bloque cet effort et prendrons les mesures nécessaires pour le rendre possible.

Débogage et profilage des performances accélérés avec Angular DevTools

Nous travaillons sur un outillage de développement pour Angular qui fournit des utilitaires de débogage et de profilage des performances. Ce projet vise à aider les développeurs à comprendre la structure des composants et la détection de changements dans une application Angular.

Simplifier les sorties grâce à une gestion des versions et des branches Angular unifiée

Nous voulons unifier l'outillage de gestion des sorties entre les différents dépôts GitHub d'Angular (angular/angular, angular/angular-cli et angular/components). Cet effort nous permet de réutiliser l'infrastructure, d'unifier et de simplifier les processus, et d'améliorer la fiabilité de notre processus de sortie.

Plus de cohérence pour les développeurs grâce à la standardisation des messages de commit

Nous voulons unifier les exigences et la conformité des messages de commit dans les dépôts Angular (angular/angular, angular/components et angular/angular-cli) afin d'apporter de la cohérence à notre processus de développement et de réutiliser l'outillage d'infrastructure.

Faire passer l'Angular Language Service à Ivy

L'objectif de ce projet est d'améliorer l'expérience et de supprimer une dépendance héritée en faisant passer le Language Service à Ivy. Aujourd'hui, le Language Service utilise encore le compilateur et la vérification de types de View Engine, même pour les applications Ivy. Nous voulons utiliser le parser de templates d'Ivy et sa vérification de types améliorée pour l'Angular Language Service, afin de correspondre au comportement de l'application. Cette migration est aussi une étape vers le déblocage de la suppression de View Engine, qui simplifiera Angular, réduira la taille du package npm et améliorera la maintenabilité du framework.

Une sécurité renforcée grâce aux Trusted Types natifs dans Angular

En collaboration avec l'équipe sécurité de Google, nous ajoutons la prise en charge de la nouvelle API Trusted Types. Cette API de la plateforme web aide les développeurs à construire des applications web plus sûres.

Vitesse de build et taille des bundles optimisées avec webpack 5 dans l'Angular CLI

Dans le cadre de la v11, nous avons introduit une préversion optionnelle de webpack 5 dans l'Angular CLI. Pour garantir la stabilité, nous continuerons d'itérer sur l'implémentation afin d'améliorer la vitesse de build et la taille des bundles.

Des applications plus rapides grâce à l'intégration des styles critiques dans les applications Universal

Le chargement de feuilles de style externes est une opération bloquante : le navigateur ne peut pas commencer à rendre votre application tant qu'il n'a pas chargé tout le CSS référencé. La présence de ressources bloquant le rendu dans l'en-tête d'une page peut avoir un impact important sur ses performances de chargement, par exemple sur son first contentful paint. Pour rendre les applications plus rapides, nous avons collaboré avec l'équipe Google Chrome pour intégrer en ligne le CSS critique et charger le reste des styles de manière asynchrone.

Améliorer le débogage grâce à de meilleurs messages d'erreur Angular

Les messages d'erreur fournissent souvent peu d'informations exploitables pour aider les développeurs à résoudre les problèmes. Nous avons travaillé à rendre les messages d'erreur plus faciles à explorer en ajoutant des codes associés, en rédigeant des guides et d'autres contenus pour faciliter le débogage.

Une meilleure prise en main pour les développeurs grâce à une documentation d'introduction remaniée

Nous redéfinirons les parcours d'apprentissage des utilisateurs et remanierons la documentation d'introduction. Nous expliquerons clairement les avantages d'Angular et comment explorer ses capacités, et nous fournirons des conseils pour que les développeurs maîtrisent le framework le plus rapidement possible.

Étendre les bonnes pratiques des harnais de composant

L'Angular CDK a introduit le concept de harnais de test de composant dans Angular avec la version 9. Les harnais de test permettent aux auteurs de composants de créer des API prises en charge pour tester les interactions avec les composants. Nous continuons d'améliorer cette infrastructure de harnais et de clarifier les bonnes pratiques concernant leur utilisation. Nous travaillons également à favoriser l'adoption des harnais au sein de Google.

Rédiger un guide sur la projection de contenu

La projection de contenu est un concept central d'Angular qui n'occupe pas la place qu'il mérite dans la documentation. Dans le cadre de ce projet, nous voulons identifier les cas d'usage et concepts clés de la projection de contenu et les documenter.

Migrer vers ESLint

Avec la dépréciation de TSLint, nous passerons à ESLint. Dans le cadre de ce processus, nous veillerons à assurer la rétrocompatibilité avec notre configuration TSLint recommandée actuelle, nous mettrons en place une stratégie de migration pour les applications Angular existantes et nous introduirons de nouveaux outils dans la chaîne d'outils de l'Angular CLI.

Opération Bye Bye Backlog (aussi appelée Opération Byelog)

Nous consacrons activement jusqu'à 50 % de notre capacité d'ingénierie au tri des issues et des PR, jusqu'à ce que nous ayons une compréhension claire des besoins plus larges de la communauté. Ensuite, nous consacrerons jusqu'à 20 % de notre capacité d'ingénierie au traitement rapide des nouvelles contributions.