Oui, Vue 3 est sorti et vous devriez considérer d’y migrer
En plus des traditionnels articles et sorties de la semaine, nous vous proposons une analyse un peu plus poussée sur des sujets qui nous tiennent à coeur.
Pour cette première, penchons-nous sur les arguments exposés dans l’article “Yes, Vue 3 is out but you probably don’t need it 🤷♂️”. Je n’ai malheureusement pas trouvé le nom de la personne ayant rédigé cet article et devrais me contenter de le nommer “l’auteur”.
Quelques précisions avant de rentrer dans le vif du sujet, il n’est pas question de déconstruire entièrement l’article ni d’essayer de le discréditer. Il me semble cependant important d’apporter un autre point de vue (🙃) sur certaines questions abordées dans l’article, afin de vous donner toutes les clefs pour savoir si vous n’avez vraiment pas besoin de passer à Vue 3 🤷♂️
Tout d’abord, je rejoins entièrement l’auteur sur le sujet de l’engouement. Il y a énormément de bonnes raisons de migrer vers une nouvelle version majeure : corriger des failles de sécurité, améliorer les performances ou encore augmenter la vélocité de l’équipe lorsque la nouvelle version introduit des outils le permettant.
Migrer un projet dans une nouvelle version majeure uniquement pour suivre la mode actuelle, ça peut être tentant, mais ça n’a rien de productif. On ne produit aucune valeur pendant ce temps et, pire, on risque de perdre en vélocité pendant le temps la montée en compétence de l’équipe ou encore en découvrant des problèmes apportés par cette nouvelle version.
Autre point entièrement objectif présenté par l’auteur : la compatibilité IE11. Si votre produit doit être compatible avec ce navigateur, ce n’est pas le moment de migrer puisque Vue 3 ne le gère pas encore.
Les points sur lesquels j’aimerais revenir et sur lesquels nous ne sommes apparemment pas en accord me semblent plus subjectifs. Ils concernent deux problèmes soulevés par l’auteur et les solutions de contournement proposées.
Le premier point concerne l’extraction de logique réutilisée à plusieurs endroits dans l’application. Ce point est traité par les versions précédentes de Vue via les “mixins”. Ces dernières permettent d’injecter de la logique dans plusieurs composants, en ajoutant notamment des data, des computed, methods et autres lifecyle hooks.
Le problème ? Une fois injectés, ces éléments sont rendus disponibles de façon transparente dans les composants, on ne sait donc pas quel mixin a injecté quelles options, et on introduit un risque de collision lorsqu’on injecte plusieurs mixins.
La solution proposée par l’auteur consiste à créer une “factory de mixins”, permettant de préciser un contexte (ou namespace) qui sera ajouté devant chaque option injectée.
La problématique de conflit dans les noms des options semble donc corrigée, mais de façon transparente une fois encore. Il nous faut toujours parcourir les mixins pour savoir quelles données sont misent à disposition.
Les Renderless Components, tels évoqués par Adam Wathan, sont aussi proposés en solution alternative.
Il s’agit, selon moi, d’un très bon pattern pour séparer intention et implémentation, je l’utilisais très souvent et peux attester des avantages en terme de lisibilité et maintenabilité. Problème, on ajoute un composant dans l’arbre pour chaque utilisation d’un renderless component et on complexifie grandement la partie HTML qui devrait être réservée au templating. Ce pattern est toujours utilisable, mais il semble moins intéressant que l’utilisation combinée des Composition et Reactive APIs.
Dernier point abordé sur lequel j’aimerais revenir, le fait de se passer de la Composition API dans des cas d’usages où les hooks peuvent être utilisés plus intelligemment.
L’exemple utilisé est effectivement plus simple sans Composition API, mais il ne présente qu’une toute petite feature, un timeout à initialiser et détruire, sans donnée exposée. La Composition API est prévue pour faire — justement — de la composition de plusieurs features de toutes tailles sans polluer le composant de détails d’implémentation.
On ne répond pas au problème de lisibilité lorsque le composant aura plus de tâches, autres que la gestion d’une sauvegarde automatique.
On ne profite pas non plus de la possibilité de séparer intention et implémentation. Ce dernier point peut sembler peu important pour un simple interval, mais il est crucial pour la maintenabilité du projet au long terme.
En résumé, rien ne vous oblige effectivement à passer sur Vue 3, mais il serait dommage de ne pas profiter des nouvelles fonctionnalités pour rendre votre code plus lisible et maintenable au fil des nouveaux développements.
Je vous encourage grandement à lire l’article en question et nous partager votre ressenti face à cette problématique de montée de version !
J’ai moi-même écrit une série d’articles sur la dernière version de Vue 3, n’hésitez pas à les parcourir pour aller plus loin sur le sujet 😁
Un grand merci à Axel pour la relecture !
