Pourquoi $any() est un faux ami dans les templates Angular et comment le remplacer par l'optional chaining, les template reference variables et le narrowing.
Sommaire
- Un crash en prod causé par un $any()
- À quoi sert vraiment $any() (et pourquoi il existe)
- Le piège démontré : $any(user).name vs user?.name
- Le cas du $event.target : contourner le typage
- Template reference variable vs cast as HTMLInputElement
- Appels de fonction et de méthode en toute sécurité
- Le cas des unions : narrowing runtime
- ?? et court-circuit : compléter le ?.
- strictTemplates : rendre les erreurs visibles
- Checklist : quand utiliser quoi
- Conclusion
Un crash en prod causé par un $any()
Vendredi, 17 h. Le tableau de bord est en production depuis dix minutes quand Sentry s'illumine : TypeError: Cannot read properties of null (reading 'name'). Le coupable ? Une seule ligne dans un template Angular :
Bonjour {{ $any(user).name }}
Le développeur avait écrit $any(user) pour « faire taire le compilateur » qui se plaignait. Le build est passé. Les tests aussi. Et pourtant, dès qu'un utilisateur arrive sur la page
*avant*
que la requête HTTP n'ait renvoyé son profil, user vaut null, et l'application plante. $any() n'avait protégé de rien : il avait juste
caché le problème jusqu'en production
.
Attention aux assistants IA.
Beaucoup de générateurs de code (ChatGPT, Copilot et consorts) proposent encore $any(...) dès qu'une erreur de typage apparaît dans un template, parce que c'est le moyen le plus rapide de « faire compiler ». C'est un très mauvais réflexe : relisez systématiquement le code généré et remplacez chaque $any() par l'outil adapté — optional chaining, template reference variable ou narrowing. Une suggestion qui compile n'est pas une suggestion qui est correcte.
Mostra le tue capacità professionali all'azienda, compila il form e lascia un tocco personale nella lettera di presentazione, aiuterà il recruiter nella scelta del candidato.