Résumé de la conférence Vue.js Amsterdam 2018

Article écrit par Tom Panier

Avec Victor et Gaëtan, nous avons assisté à la conférence Vue.js s’étant tenue à Amsterdam à la mi-février 2018.

Vous trouverez dans ce billet notre retour sur les différentes interventions auxquelles nous avons pu assister et ce que nous avons retenu de cette journée.

Evan You (créateur de Vue.js) : keynote d’ouverture

Après un retour sur les débuts de Vue.js et un état des lieux de l’écosystème à ce jour, Evan a provoqué l’allégresse de l’assemblée avec l’annonce de la version 3 de vue-cli :

• les templates disparaissent au profit d’un système de plugins, plus faciles à faire évoluer dans le temps, y compris sur des projets existants (@vue/cli-plugin-*) ;
• ces plugins, par défaut, nécessitent zéro configuration pour fonctionner, mais restent évidemment configurables ; d’ailleurs, la complexité de la configuration de Webpack, par exemple, est désormais abstraite dans un fichier vue.config.js, afin de faciliter la prise en main et la personnalisation des applications générées ;
• la commande vue init est désormais un alias pour le tout nouveau vue-create, lequel propose trois choix de socle : « basic » (Babel et ESLint), « everything » (toute la stack proposée par les templates les plus complets jusqu’ici), ou « manually pick features » (qui permet de choisir « à la carte » les éléments à intégrer parmi ceux disponibles avec la seconde option, puis de sauvegarder ses choix en tant que preset réutilisable) ;
• les différents outils tiers sont lançables via la commande vue-cli-service (de fait notamment utilisée dans la partie script du fichier package.json) ;
• D’autres nouvelles commandes font leur apparition :
  • vue serve path/to/SomeComponent.vue permet d’effectuer le rendu d’un composant en autonomie dans le navigateur : extrêmement pratique en développement !
  • vue build path/to/SomeComponent.vue permet, de la même manière, de construire un package contenant un composant et toutes ses dépendances (à noter que plusieurs « formats » de build sont disponibles, notamment les web components !).

Cette nouvelle version pleine de promesses est en beta depuis le jour de la conférence, donc courez l’essayer !

Les nouveautés de la version 2.6 du framework lui-même ont également été annoncées :

• une meilleure gestion des erreurs asynchrones ;
• un meilleur affichage des warnings ;
• le support des itérateurs pour v-for.

Une branche alternative 2.6-next fait également son apparition, laquelle abandonne le support des navigateurs obsolètes (je vous laisse deviner le·s·quel·s) et en tire parti pour améliorer drastiquement le code (utilisation de la version courante d’ECMAScript, nouvelle version du système de réactivité basée sur les proxies qui permettra de contourner les limitations de la version actuelle) pour une API identique « à 99% ». Cette version préfigure ce à quoi ressemblera le framework en version 3.

Enfin, quelques évolutions à venir ont également été annoncées pour Vuex :

• une API plus simple basée sur async / await ;
• une (possible) fusion des actions et des mutations, la distinction étant peu utile à l’usage.

Roman Kuba : « Scaling Vue in an existing stack »

Cette conférence était un retour d’expérience (en l’occurrence, celui de CodeShip) sur l’intégration progressive de Vue.js sur un projet existant, qui se voulait plus philosophique que technique. On retiendra une astuce simple mais efficace pour passer de la configuration à un petit bout de Vue.js au milieu d’une page gérée par une autre techno :

<div data-something="coucou"></div> 

beforeMount() {   this.something = this.$el.dataset.something; } 

Guillaume Chau : « Apollo, GraphQL and Vue : the ultimate stack »

Après un rappel de ce qu’est GraphQL, Guillaume nous a parlé d’Apollo et, enfin, de la bibliothèque vue-apollo qui permet l’intégration de ce dernier avec Vue.js, un aspect qui aurait hélas mérité d’être plus détaillé.

La bibliothèque fournit plusieurs composants permettant l’utilisation d’Apollo directement au sein de votre code Vue, notamment <ApolloQuery /> pour des requêtes « simples » et <ApolloSubscribeToMore /> pour des… souscriptions. Pour plus de détails, le plus simple sera encore de lire la doc !

Il est à noter que cette bibliothèque est déjà compatible avec la version 3 de vue-cli, étant disponible en tant que plugin tel qu’évoqué plus haut.

Alexandre Chopin : « Speed up your Vue.js development time with Nuxt.js »

Alexandre, l’un des deux « Chopin brothers » à l’origine du server-side rendering framework Nuxt.js, construit autour de Vue, nous a présenté ledit outil, de son historique à sa version stable actuelle. Je ne vais pas m’étendre sur le sujet, un article complet étant dans les tuyaux chez nous 😉

Eduardo San Martin Morote : « State animations : getting them right »

Destinée à détailler l’un des points forts de Vue.js, à savoir sa gestion des animations CSS et/ou JS en fonction du state de vos composants, cette allocution était aussi divertissante qu’instructive !

Elle commençait donc par un bref rappel des outils mis à disposition nativement par le framework (à savoir <Transition /> et <TransitionGroup />), tout en rappelant que leur principale fonction, si utilisés seuls, consistait essentiellement à ajouter ou retirer des classes CSS, et limitait donc le développeur à l’usage des animations idoines. Eduardo rappelait au passage une petite astuce permettant facilement de mettre en place une animation sur chaque changement de route :

<transition name="fade">   <router-view :key="$route.fullPath" /> </transition> 

Pour ce qui est des animations JS, nous avons eu droit à une bonne explication de leur nature, qui les sépare en deux groupes :

• easing (d’un état A à un état B en une durée donnée avec un parcours donné) :
  • avantage : contrôle plus fin sur le déroulé ;
  • inconvénient : peut être coupé en cours de route ;
  • utile pour un élément rebondissant, par exemple.
• spring (d’un état A à un état B à une vitesse donnée) :
  • avantage et inconvénient inverses, logiquement ;
  • donne un rendu plus proche d’un moteur physique, plus « naturel » ;
  • utile pour les barres d’un graphique, par exemple.

Eduardo a poursuivi en nous présentant deux bibliothèques qu’il a respectivement conçues pour chaque type d’animation, et qui feront, à n’en pas douter, date dans l’écosystème Vue.js :

• vue-tweezing pour les easings, s’appuyant sur Tween.js (la bibliothèque de référence dans le domaine mais très verbeuse à l’usage) par défaut ;
• vue-motion pour les springs.

Dans les deux cas, l’API consiste en un composant contenant un slot pour votre propre code (comme les deux composants natifs susmentionnés). Fonctionnalité intéressante, <tweezing /> permet de définir un autre référentiel que le temps (position du curseur ou du scroll, par exemple).

Le mot de la fin, provoquant l’hilarité de la salle, fut une démo d’animation d’un élément <audio /> en accélérant et ralentissant un son de différentes manières. Très efficace !

Plamen Zdravkov : « Building reusable UI components in Vue »

Ce que nous pensions être un ensemble de guidelines destinées à garantir la réutilisabilité des composants Vue s’est avéré être un tour d’horizon des bases du framework. On s’interrogera sur la pertinence d’expliquer à l’assemblée de la conférence Vue.js ce qu’est une computed ; enfin, un rappel ne fait, bien évidemment, jamais de mal !

Edd Yerburgh : « Unit testing Vue components : the what, why, and how »

Là encore, la conférence s’est révélée être un tour d’horizon assez basique des tests unitaires en général (principe et philosophie), avec une application à Vue assez limitée, bien qu’il faille reconnaître que grâce à Jest (et vue-test-utils, même s’il ne fait apparemment « que » simplifier l’API), ceux-ci deviennent un jeu d’enfant à écrire. Le tour d’horizon en question était en tout cas intéressant et bien mené, incluant notamment le protocole des tests de snapshots HTML proposés par Jest :

• sauvegarder dans un fichier local (et .gitignoreé) le HTML généré par le rendu du composant testé unitairement lors de la première exécution ;
• comparer ce snapshot au HTML généré lors des exécutions suivantes pour garantir la non-régression dudit composant ;
• permettre de mettre à jour le snapshot via l’option -u.

J’ai juste un doute quant à la suggestion d’Edd de tester le fait que quand on insère du markup dans le slot d’un composant, celui-ci est bien rendu tel quel : non seulement cela ne teste pas le composant, mais Vue lui-même (et il ne s’agit donc pas un test unitaire, de mon point de vue), mais de plus, c’est une opportunité supplémentaire de casser les tests de snapshots susmentionnés.

Sébastien Chopin : « How to server-render a Vue.js application »

Faisant suite à la conférence d’Alexandre, son frère nous a quant à lui parlé de server-side rendering avec Vue.js en général, en présentant au travers d’une démo pratique à étapes successives le principe de base et les outils mis à disposition, à nouveau, par le framework.

Pour ne pas paraphraser inutilement la documentation idoine, très complète, retenons simplement quelques points d’intérêt cités en fin d’exposé :

• le module instanciant l’application Vue côté serveur doit absolument s’appuyer sur une fonction qui sera exécutée à chaque requête, sans quoi plusieurs utilisateurs risquent de partager la même instance, et donc le même state, ce qui serait fort inopportun en plus d’être une potentielle faille de sécurité ;
• il faut à tout prix éviter de lancer un timer avec setTimeout ou setInterval dans le handler beforeCreate ou created d’un composant pour le même genre de raison, sans quoi autant de timers que de requêtes seront lancés, ce qui peut causer assez rapidement une fuite mémoire importante ; de plus, notons que ni beforeDestroy ni destroyed ne sont appelés côté serveur.

La conclusion tendait à inviter l’auditoire à utiliser, bien évidemment, Nuxt.js pour mettre en place le rendu côté serveur sur son application ; promis, vraiment, on vous en parle bientôt !

Gerard Sans : « Moving from Angular to Vue »

Une fois de plus, nous avons été induits en erreur par l’intitulé du talk : en lieu et place du sujet purement technique attendu, nous avons eu droit à un comparatif global (tant sur le style de code et les performances que sur la communauté) entre les deux frameworks, de la part d’un développeur expert Google tombé sous le charme du V vert. Peu à retenir en pratique, mais c’était aussi amusant que prenant.

Le reste de la journée

Faute de temps, nous n’avons malheureusement pas pu assister aux trois dernières allocutions de la journée, à savoir « Vue development in CodeSandbox » par Ives Van Hoorne (un sujet sûrement très intéressant, bien que prochainement rendu désuet par vue serve, mentionné plus haut), « Create an engaging native mobile app with Vue and NativeScript », par Jen Looper (senior developer advocate chez Progress, société ayant créé NativeScript et sponsor platinum de l’évènement, de qui on pouvait donc potentiellement attendre une conférence « publicitaire », même si découvrir davantage l’outil m’aurait plu), et « Serverless functions and Vue.js », par Sarah Drasner (« serverless » étant le nouveau buzzword pour « site statique », et Vue étant un outil très en vogue sur ce terrain). Si certain·e·s parmi vous ont assisté à ces interventions (ou aux précédentes), n’hésitez pas à nous dire en commentaire ce que vous en avez pensé !