Le socle commun des frameworks

Le socle commun des frameworks

1. Pourquoi un framework, et qu'est-ce qu'il règle

   Un framework n'accélère pas le code. Il change la façon dont on décrit l'interface, et c'est là qu'est le gain.

   Le problème concret

   Sans outil, on écrit à la main trois choses à chaque modification de l'écran : retrouver l'élément du DOM, le mettre à jour, et gérer le cas où l'état a changé entre deux actions de l'utilisateur. Ce code est fait de cas particuliers, et il en manque toujours un.

   Un framework inverse la responsabilité : on décrit ce que l'écran doit afficher pour un état donné, et lui se charge de calculer la différence avec l'écran réellement affiché. C'est une description, pas une séquence d'instructions.

   La notion d'état

   L'état est la donnée qui décrit la situation courante : l'utilisateur connecté, la panier, la valeur d'un champ, l'état de chargement. Un composant est une fonction de l'état vers l'affichage.

   La conséquence pratique est la plus importante du cours : deux états qui produisent le même écran n'ont aucune raison d'être distincts. Corriger l'état plutôt que l'affichage — au lieu de « cacher le bouton », on change l'état qui décide de son affichage. C'est la source de la majorité des bugs évités.

   Ce qu'un framework ne règle pas

   • la structuration du code à grande échelle, qui relève de l'architecture ;
   • la performance réseau, qui relève du serveur ;
   • le référencement des contenus rendus côté client, qui reste un vrai sujet ;
   • les tests, qui restent à écrire.

   Un framework bien maîtrisé dans une mauvaise architecture produit une application inutilisable. L'inverse est vrai aussi.

2. React, Angular, Vue : trois arbitrages

   Les trois sont des réponses au même problème. Les présenter comme « le bon », « le mauvais » est une erreur : ils optimisent pour des contraintes différentes.

   Critère	React	Angular	Vue
   Philosophie	bibliothèque, on assemble	framework complet, tout fourni	incrémental, on choisit le niveau
   Langage	JavaScript, TypeScriptoptionnel	TypeScript obligatoire	JavaScript, TypeScript optionnel
   Outillage	à choisir soi-même	fourni et cohérent	progressif, migration possible
   Conventions	peu, donc libre	fortes, donc cadrées	faibles à moyennes

   Comment on choisit vraiment

   1. React si l'équipe veut décider de son architecture, si l'ecosysteme de bibliotheques disponibles compte, ou si des compétences React existent déjà.
   2. Angular si l'application est large, avec beaucoup d'écrans et une équipe à encadrer : les conventions et l'outillage intégré limitent les arbitrages et donc les désaccords.
   3. Vue si on veut un point d'entrée simple, une migration progressive depuis du HTML existant, ou une montée en puissance graduelle.

   L'argument qui tranche le plus souvent

   Le critère décisif n'est presque jamais technique : c'est ce que l'équipe saura maintenir dans deux ans. Un framework impair son état s'explique en une phrase ; une pile mal choisie se decouvre a la premiere evolution, quand le code est deja en production. Ce cours présente les trois, mais il ne prétend pas qu'il y en a une bonne : les étudiants devront trancher pour un besoin donné, et savoir justifier ce choix.

3. TypeScript : l'outillage commun

   Quel que soit le framework, TypeScript est devenu l'attente par défaut sur du code qui dépasse quelques centaines de lignes. Il vérifie les types à la compilation, ce qui déplace la détection d'erreur du moment où l'utilisateur clique vers celui où le code est écrit.

   Ce que le type apporte

   • les erreurs avant exécution : un mauvais nom de propriété est refusé à la compilation ;
   • de l'autocomplétion fiable : l'éditeur sait ce que contient un objet, donc il propose les vraies propriétés ;
   • une documentation qui ne peut pas mentir : c'est la signature d'une fonction ;
   • du refactoring sûr : renommer une propriété dans tout le projet est immédiat.

   Le piège : laisser croire à une garantie

   Le type ne vérifie pas la logique. Il vérifie la cohérence des formes, pas l'exactitude des comportements. Un tableau typé comme un tableau de nombres reste faux si on y met des nombres au hasard.

   Erreur fréquente en formation : écrire as ou any pour faire disparaître une erreur de type. Le message ne disparaît pas, il perd sa valeur : la vérification a été désactivée sur ce point, et le bug est maintenant invisible au lieu d'être signalé.

   La règle que ce cours applique

   Un transtypage doit être justifié par un motif réel, et écrit en commentaire. Un any non expliqué est un bug en attente. Les tests ci-dessous rendent la violation visible.