Angular a longtemps eu la réputation d’être puissant mais exigeant, difficile à appréhender au début (beaucoup de chose à comprendre). A partir d’Angular 14, la Team Angular a fait le nécessaire pour palier et ce problème ,la version 22 est la version mature de cette migration : le framework a fait peau neuve, et la réactivité y est devenue une affaire de bon sens plutôt que d’expertise.
Angular fait peau neuve
La simplification a été progressive, Angular a intégré une série de changements qui, chacun, retire une couche de complexité historique.
Les composants autonomes d’abord. Fini les NgModule : chaque composant vit désormais tout seul. Il déclare lui-même ce qu’il importe, se suffit à lui-même, et n’a plus à être rattaché à un module. Une classe, un décorateur, et c’est un composant complet. Toute une catégorie de questions qui déroutaient les débutants, où déclarer ce composant, quoi exporter, pourquoi cette erreur de module, a simplement disparu.
Le control flow ensuite. Les directives structurelles *ngIf et *ngFor, avec une syntaxe peu intuitive, cèdent la place à une syntaxe intégrée au langage de template, immédiatement lisible et qui s’aligne à ce que vous faites d’habitude (on englobe ce qu’on veut gérer on n’ajoute pas le contrôle à l’intérieur) :
On lit @if, @for, @else, @empty comme on lit du code. Rien à importer, rien à mémoriser, et le compilateur vérifie tout.
Et la liste continue dans la même direction : les bons réglages sont devenus les défauts. Plus besoin de déclarer standalone: true ni la stratégie de détection de changements optimale, le framework choisit pour vous la voie moderne.
Les signaux : penser déclaratif, enfin
Prenons un formulaire qui doit afficher la somme de deux valeurs saisies. Le réflexe historique :
Le problème est subtil mais fondamental : cette ligne n’exprime pas « z est la somme de x et y ». Elle ne fait qu’initialiser z avec la somme au moment précis où la classe se construit. Si x change, z reste figé à 5, et c’est à vous d’y penser, à chaque endroit du code qui touche à x ou y.
Or, ce n’est pas ainsi que nous raisonnons. Dans notre modèle mental, « z, c’est la somme de x et y », une définition, pas une affectation. C’est toute la différence entre programmation impérative (dire à la machine quoi faire, étape par étape) et programmation déclarative (dire ce qui est vrai, et laisser le système le maintenir).
C’est exactement ce que les signaux apportent, avec l’API computed :
z est désormais une valeur calculée déclarée. À chaque modification de x ou de y, il est recalculé et tous ceux qui l’affichent sont notifiés, automatiquement, sans abonnement, sans événement, sans oubli possible. Le template qui affiche {{ z() }} se met à jour tout seul, et le tour est joué.
Autour de ce principe, la famille d’API est petite et cohérente : signal() pour un état qui change, computed() pour tout ce qui s’en déduit, effect() pour les rares réactions vers le monde extérieur, et linkedSignal() pour un état local qui se réinitialise quand sa source change. Quatre outils, un seul modèle mental : déclarer, et laisser le framework maintenir.
Les resources : l’asynchrone sans la plomberie
Pour faire des appels HTTPs on passait avant par la bibliothèque RxJs, puissante elle permet de gérer les flux asynchrones, mais elle représentait la hantise de plusieurs développeurs Angular et les nouveaux apprenants. Le problème avec RxJs c’est que pour faire un simple appel http, elle imposait un rituel disproportionné : s’abonner, se désabonner au bon moment, gérer soi-même l’état de chargement et l’erreur, connaître switchMap pour annuler la requête précédente. Autant de complexité qui n’avait rien à voir avec le besoin.
Les resources, stabilisées avec httpResource et rxResource, ramènent ce cas courant à sa juste taille :
Tout y est, déclaré une fois : la requête se relance seule quand le InputSignal cvId change, et vous disposez de cvResource.value(), cvResource.isLoading() et cvResource.error() sous forme de signaux prêts à afficher. Ni abonnement, ni désabonnement, ni état de chargement à bricoler. Et quand un flux mérite vraiment les opérateurs de RxJS, rxResource fait le pont : la puissance des opérateurs à l’intérieur, la simplicité des signaux à l’extérieur.
Ce qu’il faut retenir
Composants autonomes, control flow intégré, signaux, resources : quatre visages d’une même idée. Angular a remplacé ses rituels par des déclarations, et son ancienne courbe d’apprentissage par un modèle mental unique : décrivez ce qui est vrai, le framework s’occupe du reste. C’est un framework qu’on apprend plus vite, et dans lequel on se trompe moins tout en gardant sa robustesse, ses patrons de conception et une architecture robuste, maintenable et scalable.
