Angular : le framework complet

Angular : le framework complet

1. L'outillage intégré et les conventions

   Angular n'est pas une bibliothèque d'interface, c'est un framework. Il fournit le routeur, les formulaires, le client HTTP, la compilation, les tests et l'outillage de build dans une seule chaîne cohérente.

   Ce que cela change concrètement

   • moins de décisions à prendre au départ : routeur, gestion d'état, requêtes HTTP et tests viennent ensemble, dans une version cohérente ;
   • des conventions fortes : l'organisation des fichiers et le nommage des éléments suivent un modèle documenté. Pour une équipe nombreuse, cela réduit les désaccords d'architecture ;
   • TypeScript obligatoire : c'est un prérequis, pas une option, ce qui veut dire que la vérification de types fait partie du flux normal de travail.

   Le prix à payer est la courbe d'apprentissage : plus de concepts à connaître avant d'écrire une première ligne. Le choix se joue là — sur la taille de l'équipe et sur la complexité attendue de l'application, pas sur une préférence de syntaxe.

2. Les signaux et la détection de changement

   Le modèle historique d'Angular repose sur la détection de changement : l'Angular parcourt l'arbre des composants et vérifie ce qui a changé. Les signaux introduisent un modèle où la dépendance est déclarative : un composant indique qu'il utilise une valeur, et il n'est rejoué que si cette valeur change.

   Signaux et valeurs calculées

   Un signal est une valeur qui « porte » sa dépendance. Une valeur calculée se dérive d'autres signaux et ne se recalcule que si une de ses sources a changé. Le résultat est le même écran, mais le travail est limité au sous-arbre réellement concerné.

   Ce que cela change en pratique

   • moins de vérifications inutiles : un composant qui ne lit pas un signal n'est pas rejoué pour lui ;
   • moins d'incohérences temporelles : dans un modèle à détection de changement, mettre à jour une valeur dans un callback asynchrone peut produire un état intermédiaire incohérent selon l'ordre des écritures. Le modèle par signal rend ces situations explicites ;
   • un coût de conception : la règle « lecture dans un gabarit = dépendance » doit être comprise, sinon on introduit des dépendances involontaires sans s'en apercevoir.

   La leçon qui vaut pour les trois frameworks : une règle de dépendance explicite coûte moins cher qu'une dépendance implicite qu'on découvre en production.

3. Formulaires, requêtes et gestion d'erreur

   L'outillage Angular brille sur les deux besoins quotidiens d'une application d'entreprise : formulaires et accès aux données.

   Formulaires typés et validations

   Les formulaires réactifs décrivent le modèle et les règles de validation dans le code, indépendamment du gabarit. Deux bénéfices directs : les règles sont testables sans navigateur, et la validation peut être partagée entre le formulaire et une soumission programmatique.

   Le point où la plupart des projets déraillent

   Une application réelle a trois états par requête réseau, et il faut les traiter tous les trois :

   1. chargement : l'utilisateur a déclenché l'action, rien n'est encore revenu ;
   2. succès : la donnée est arrivée ;
   3. échec : le réseau a échoué, le serveur a répondu en erreur, ou la réponse est inexploitable.

   Traiter seulement le succès est l'erreur la plus répandue du domaine. L'utilisateur clique, rien ne se passe, et l'application passe pour cassée. Le chargement doit bloquer l'action pour éviter les doubles envois, et l'erreur doit être visible et actionnable — jamais un échec silencieux.

   Annulation et course des requêtes

   Un dernier piège, plus rare mais plus coûteux : si l'utilisateur déclenche deux fois une recherche, les réponses peuvent revenir dans le désordre. La réponse la plus ancienne peut alors écraser la plus récente, affichant des résultats qui ne correspondent pas à la dernière saisie. Les bibliotheques modernes fournissent un mécanisme d'annulation ; s'il est ignoré, ce defaut est pratiquement impossible à reproduire en test et se manifeste sporadiquement chez les utilisateurs.