Cet article est publié sous licence CC BY-NC-SA
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.
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 :
@vue/cli-plugin-\*
) ;vue.config.js
, afin de faciliter la prise en main et la personnalisation des
applications générées ;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) ;vue-cli-service
(de fait notamment utilisée dans la partie script
du fichier
package.json
) ;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 :
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 :
async
/ await
;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;
}
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, 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 ;)
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 :
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 :
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 !
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 !
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 :
.gitignore
é) le HTML généré par le
rendu du composant testé unitairement lors de la première exécution ;-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.
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é :
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 !
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.
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é !
L’équipe Synbioz.
Libres d’être ensemble.
Nos conseils et ressources pour vos développements produit.