Vue : le framework progressif

Vue : le framework progressif

1. La progression par niveaux

   Vue se définit par une propriété précise : il peut être introduit par petits morceaux dans une page existante, sans réécrire l'application.

   Les quatre niveaux d'usage

   1. dans le gabarit : une interpolation ou une directive dans une page HTML existante ;
   2. un composant isolé : un bloc réutilisable monté sur une page qui n'a pas été convertie ;
   3. une application à un fichier : un composant racine qui contient tout ;
   4. une application complète : routeur, gestion d'état, outillage de build, tests.

   Cette propriété a une conséquence très concrète : sur un site existant, on peut commencer par le seul composant qui pose problème, et décider plus tard si on va plus loin. C'est souvent ce qui rend Vue convaincant pour une équipe qui part d'un parc applicatif existant.

   La réactivité par proxy

   Vue transforme l'objet de données du composant en objet surveillé. Quand une propriété est lue dans un gabarit, l'accès est enregistré ; quand elle est écrite, le rendu correspondant est déclenché. L développeur écrit l'état et le gabarit, sans décrire la mise à jour.

   La conséquence à connaître : la réaction est déclenchée par la lecture dans un gabarit ou un observateur. Une propriété lue uniquement dans du code ordinaire ne déclenche rien — ce qui est correct, mais surprend si on l'attendait autrement.

2. Composants à fichier unique et composition

   Un composant Vue tient dans un fichier, qui contient ensemble le gabarit, le script et le style. C'est l'inverse de la séparation stricte en plusieurs fichiers, et c'est un choix d'outillage autant que d'architecture.

   Pourquoi tenir à un seul fichier

   • le composant se lit d'un bout à l'autre, sans aller chercher une autre extension ;
   • le style peut être associé au composant et embarqué dans le paquet, ce qui évite les collisions de noms globaux ;
   • les trois balises sont décoratives et ignorées à la compilation : le même fichier décrit la logique et sa présentation.

   Composition : la règle des petits composants

   Un composant qui contient six zones fonctionnelles distinctes est un composant à six problèmes. Le découpage n'est pas une question de taille de fichier : c'est une question de raison d'être.

   Test simple à appliquer : si une partie du composant peut être décrite par une phrase qui commence par « il affiche », cette partie est probablement un composant distinct. Le bénéfice n'est pas la Reduction du fichier, c'est la testabilite : un composant affichant « l'utilisateur connecté » se teste seul, sans approvisionner tout le contexte de la page.

   Communication parent-enfant

   Comme en React, les données descendent par propriétés et les intentions remontent par événements. La cohérence entre les trois frameworks sur ce point n'est pas un hasard : c'est la solution la plus lisible quand plusieurs personnes font évoluer le même code.

3. État partagé et cycle de vie

   Quand plusieurs composants ont besoin du même état, il faut une source unique. Un store partagé évite de recopier la donnée et de la resynchroniser à la main — source classique de désynchronisation.

   Un store, pas un registre

   Un store expose des getters en lecture seule et des actions qui sont les seules à pouvoir modifier l'état. Cette discipline n'est pas cosmétique : elle rend la traçabilité immédiate. On peut répondre à « qui a modifié cette valeur » en regardant les actions, sans chercher une affectation dans tout le code.

   C'est la même exigence que les enzymes de de la duplication, appliquée à l'état : une donnée modifiable depuis partout est une donnée dont on ne saura pas qui l'a modifiée.

   Le cycle de vie, en trois temps

   1. création : le composant est instancié, son état est initialisé, ses paramètres sont lus ;
   2. montage : il entre dans le DOM, il peut mesurer, se brancher sur un événement, lancer une requête ;
   3. démontage : il le quitte, et tout ce qu'il abranché doit être débranché.

   Le troisième temps est celui qu'on oublie. Une minuterie, un écouteur d'événement global ou un abonnement laissés actifs après le démontage gardent une référence sur un composant qui n'existe plus : la mémoire ne se libère pas, et l'erreur peut se manifester beaucoup plus tard, dans un autre composant, ce qui la rend très difficile à rattacher à sa cause.