Angular 21.2 : une mise à jour discrète… mais stratégique

Angular 21.2 est une version mineure, mais elle confirme très clairement la direction prise par le framework : plus de typage, plus d’expressivité dans les templates, et une transition progressive vers un modèle réactif plus optimisé.

Voici un tour complet des nouveautés importantes.

---

Support officiel de TypeScript 6

Angular 21.2 ajoute le support de TypeScript 6.

Ce n’est pas juste une mise à jour cosmétique. Angular dépend fortement du système de types pour analyser les templates. Chaque évolution de TypeScript améliore :

• la précision des diagnostics
• la détection d’erreurs dans les templates
• la qualité de l’autocomplétion dans les IDE
• la cohérence entre le code TS et le template

Pour les équipes qui suivent de près l’évolution du langage, c’est un vrai signal de modernité.

Templates plus expressifs

instanceof dans les templates

Il est désormais possible d’utiliser instanceof directement dans les expressions Angular.

Exemple :

@if (value instanceof AdminUser) {
  <div>
    Accès administrateur
  </div>
}

Cela permet :

• un typage plus précis dans le template
• un narrowing correct par TypeScript
• moins de logique déplacée artificiellement dans le composant

Arrow functions dans les templates

Les fonctions fléchées sont maintenant autorisées dans les expressions.

Exemple :

<button (click)="items.update(list => [...list, newItem])">
  Ajouter
</button>

Avant, il fallait souvent créer une méthode dédiée dans le composant juste pour ce type d’opération.

Résultat :

• moins de boilerplate
• des interactions plus naturelles avec les Signals
• une syntaxe plus proche du TypeScript moderne

À utiliser avec modération, évidemment, pour garder des templates lisibles.

ChangeDetectionStrategy.Eager : un alias révélateur

Angular 21.2 introduit :

ChangeDetectionStrategy.Eager

Cet alias est strictement équivalent à Default.

Donc aujourd’hui :

changeDetection: ChangeDetectionStrategy.Default

et

changeDetection: ChangeDetectionStrategy.Eager

ont exactement le même comportement.

Pourquoi ce renommage ?

Le mot Default décrit une position. Le mot Eager décrit un comportement.

Ce changement prépare clairement le terrain pour un futur où :

• OnPush pourrait devenir la stratégie par défaut
• la détection serait plus optimisée
• les Signals piloteraient plus finement les mises à jour

Renommer Default en Eager permet de dissocier le comportement actuel de la notion de “valeur par défaut”.

C’est un petit changement… mais stratégiquement très parlant.

ResourceSnapshots : composer l’asynchrone proprement

Angular avait introduit les Resources, une API expérimentale pour encapsuler l’état asynchrone dans un modèle basé sur les Signals.

Une Resource contient :

• une valeur
• un état de chargement
• une erreur éventuelle

Le problème classique

Si tu as plusieurs appels asynchrones :

• userResource
• ordersResource

Tu te retrouves vite à gérer :

• loadingUser
• loadingOrders
• errorUser
• errorOrders

Bref, beaucoup de logique impérative.

Ce que 21.2 apporte

Les ResourceSnapshots permettent de capturer l’état complet d’une Resource à un instant donné, puis de les composer proprement.

Concrètement :

• si l’une des ressources charge → état global en loading
• si l’une échoue → état global en erreur
• si tout est prêt → état combiné cohérent

Sans multiplier les flags.

L’objectif est clair : rendre la gestion de l’asynchrone aussi déclarative que les computed() pour le synchrone.

Signal Forms : des améliorations concrètes

Les Signal Forms continuent d’évoluer en 21.2.

Meilleure gestion des erreurs de parsing

Les champs comme :

<input type="number">

peuvent produire des états intermédiaires invalides pendant la saisie.

Exemple :

• -
• 1.
• valeur partiellement valide

Angular 21.2 améliore la distinction entre :

• erreur de parsing
• erreur de validation métier
• état intermédiaire pendant la saisie

Cela évite des comportements trop agressifs côté validation.

Support propre de null pour les champs numériques

Il est désormais possible de lier proprement null à un champ type="number".

Cela simplifie les champs optionnels et évite :

• conversions implicites vers 0
• apparition de NaN
• incohérences entre modèle et vue

Options de focus

Les Signal Forms permettent maintenant de mieux gérer le focus des champs.

Cas typiques :

• focus automatique sur le premier champ invalide à la soumission
• contrôle plus fin du comportement UX

Moins de manipulation manuelle du DOM, moins de ViewChild juste pour déplacer le curseur.

Interop avec les Reactive Forms

L’introduction de SignalFormControl facilite l’interopérabilité avec les Reactive Forms classiques.

Cela permet :

• une migration progressive
• un usage hybride
• moins de refactor massif