Angular 19 marque une étape importante dans la maturation de la plateforme, particulièrement autour des signaux qui deviennent la pierre angulaire de la détection de changement. Cette version consolide les fondations posées en 18 en supprimant la détection de changement zone-based par défaut, forçant les projets à adopter la réactivité basée signaux. Ce n'est pas une révolution cosmétique : c'est un changement d'architecture profond qui affecte la performance, la maintenabilité et la façon dont vous pensez l'état applicatif. Si vous hésitiez encore avec les signaux en 18, vous n'aurez plus le choix en 19.
La fin de la détection de changement zone-based
La suppression de ZoneJS par défaut est le changement le plus impactant. En 18, vous pouviez encore configurer une application sans signaux et compter sur zone.js pour détecter les changements asynchrones. En 19, cela n'existe plus : le framework suppose que vous utilisez des signaux et la détection de changement OnPush. Concrètement, cela signifie que tout observable non converti en signal ne déclenchera plus de détection de changement automatiquement. Si vous avez des services qui émettent des observables et que vos composants les consomment avec l'async pipe, vous devez convertir ces observables en signaux avec toSignal(). C'est une migration qui peut être progressive mais qui doit être planifiée. Pour les applications existantes, Angular CLI fournit des codemods partiels, mais attendez-vous à devoir revoir vos patterns de détection de changement composant par composant.
Signaux et computed : le cœur réactif
Les signaux ne sont plus une feature expérimentale : ils sont le standard. La syntaxe reste identique mais elle est maintenant la voie privilégiée. Les computed signals gagnent également en robustesse avec une meilleure gestion des dépendances et une détection plus fine des changements. Si vous aviez des computed qui se recalculaient trop souvent en 18, vous verrez une amélioration nette. Angular fournit aussi des helpers supplémentaires comme effect() qui gère mieux les cleanup et les dépendances asynchrones. Un point clé : les effets ne sont plus considérés comme du code "bâtard", ils font partie de la stratégie de gestion d'état recommandée. Cela permet des patterns plus épurés pour les side-effects comme les logs, les appels API décalés ou la synchronisation d'état.
Formulaires réactifs : un nouveau groupe d'API
Angular 19 introduit une nouvelle API pour les formulaires réactifs, plus alignée avec les signaux. Les FormGroup et FormControl acceptent maintenant des signaux en entrée et émettent des signaux en sortie. Au lieu de vous abonner à valueChanges avec un observable, vous pouvez directement lire la valeur d'un signal. Cette amélioration réduit les fuites mémoire et rend le code des formulaires beaucoup plus lisible. Exemple concret : au lieu de this.form.valueChanges.pipe(debounceTime(300), distinctUntilChanged()).subscribe(...) , vous pouvez maintenant bénéficier d'une validation déclarative avec des signaux qui se synchronisent naturellement. Les FormBuilder et FormControl acceptent un nouvel argument nonNullable en configuration, ce qui réduit le boilerplate de typage.
export class MyFormComponent {
form = new FormGroup({
email: new FormControl('', { validators: [Validators.required], nonNullable: true }),
password: new FormControl('', { validators: [Validators.required], nonNullable: true })
});
email = toSignal(this.form.get('email')!.valueChanges, { initialValue: '' });
isValid = computed(() => this.form.valid);
}
Dépendances et breaking changes mineurs
La migration de la zone.js est directe mais exige de la rigueur. Les imports de zone.js dans polyfills.ts peuvent être supprimés si vous n'en aviez besoin que pour Angular. Cependant, si des librairies tierces (comme Jasmine ou certaines librairies de charting) dépendent encore de zone.js, vous devez les conserver. Angular 19 fournit une liste exhaustive des breaking changes, mais la plupart sont liés à des APIs internes ou dépréciées depuis longtemps. Le compilateur JIT a été supprimé : tous les builds utilisent maintenant Ivy et esbuild par défaut. Si vous aviez une configuration custom avec JIT, vous devez passer à AOT.
Pièges courants lors de la migration
Le piège le plus courant est de supposer que toSignal() est une solution magique pour les observables. En réalité, toSignal() crée un souscription qui persiste tant que le signal existe. Si vous l'utilisez dans un service singleton, vous devez gérer manuellement le unsubscribe ou utiliser une stratégie de destruction appropriée. Deuxième piège : oublier que les signaux sont synchrones par défaut. Si vous tentiez de lire immédiatement la valeur d'un signal provenant d'un observable asynchrone, vous obtiendrez la valeur initiale, pas la valeur mise à jour. Troisième piège courant : mélanger les patterns réactifs. Avoir une moitié de l'application en signaux et l'autre moitié en observables crée des frictions de performance et de maintenabilité. Planifiez une migration progressive mais cohérente.
Outils et ressources pour migrer
Angular CLI 19 fournit des codemods automatisés avec ng update @angular/core . Ces codemods ne sont pas parfaits mais ils gèrent les cas les plus courants : conversion basique de observables en signaux, mise à jour des imports, suppression de zone.js des polyfills. Pour les migrations complexes, utilisez les schematics Angular fournis ou écrivez les vôtres. Les tests unitaires doivent être revus : les TestBed et les async fixtures se comportent différemment avec les signaux. Angular fournit une documentation détaillée sur les migration guides avec des exemples code par domaine (formulaires, HTTP, routing).
La migration vers Angular 19 n'est pas une rustine cosmétique : c'est une opportunité pour refondre votre architecture réactive autour des signaux. Le chemin est balisé, les outils existent, mais le succès repose sur une compréhension claire des changements de paradigme, particulièrement l'abandon de la détection de changement zone-based. Commencez par les tests, puis migrez les services, puis les composants. Acceptez que cette migration prendra du temps sur une grande codebase, mais les gains en performance et en maintenabilité en valent la peine.