Article écrit par Gaëtan Dejaegere
Comme vous avez sûrement pu le constater, les articles traitant de Vue.js se multiplient sur ce blog. Cela s’explique par son adoption grandissante par nos équipes, qui apprécient sa simplicité et son écosystème florissant. Parmi les nombreux projets open source gravitant autour de celui de notre cher Evan You, un phénomène venu de nos contrées (cocorico !) suscite beaucoup d’excitation dans la communauté et a attiré notre attention : Nuxt.js.
Sortie en version 1.3 en ce début d’année, et présenté lors de la conférence Vue.js Amsterdam, ce framework nous promet de faciliter la création et le déploiement d’applications isomorphiques avec Vue.js. Tout un programme !
Isomorphique, un code pour les gouverner tous
Un peu d’étymologie pour comprendre de quoi il s’agit…
Ce terme dérive des deux racines grecques « isos » (égal) et « morphe » (forme). Concrètement, dans le domaine du développement web, une application isomorphique, également appelée « universelle », a la particularité d’exécuter un code commun côté client et côté serveur. Auparavant inconcevable, ce type d’application a vu le jour grâce à l’avènement de JavaScript en tant que langage serveur.
L’isomorphisme amène son lot d’avantages et pallie aux faiblesses de nos SPA :
- Moins de code à maintenir et par conséquent un débuggage simplifié
- Une certitude sur l’indexation des moteurs de recherche en évitant l’effet « coquille vide »
- Un affichage plus rapide, pas de chargement d’une pléthore de JavaScript avant le rendu
- Des partages sur les réseaux sociaux optimisés
Malheureusement, mettre en place une application isomorphique from scratch se révèle souvent être un parcours du combattant. C’est donc sans surprise, que chacun des frameworks populaires (React, Angular, Vue.js), ont vu naître leur pendant isomorphique respectif (Next.js, Angular Universal, et nous concernant, Nuxt.js).
Nuxt.js, petit tour d’horizon
Créé par deux français, Alexandre Chopin (@Atinux) et Sébastien Chopin (@_achopin), Nuxt.js est largement inspiré de Next.js, équivalent dans l’écosystème React.
Initialement concentré sur la partie SSR, il propose aujourd’hui une solution conçue autour de Vue.js 2 et de modules phares tels que vue-server-renderer, vue-meta, vue-router et Vuex. Ici, point d’imports manuels de librairies et de plomberie interminable, un soupçon de magie et de conventions nous offre une expérience de développement simplifiée et un vrai gain de productivité.
Ouvrons le capot et découvrons la bête qui sommeille en lui !
Installation
Après avoir installé vue-cli
, le plus simple pour commencer un projet Nuxt.js est d’utiliser le template mis à disposition par ses créateurs :
vue init nuxt-community/starter-template <mon-projet>
Puis d’installer les dépendances :
cd <mon-projet> npm install
Enfin de lancer le serveur :
npm run dev
Nous pouvons maintenant nous rendre sur localhost:3000
et profiter d’un environnement de développement moderne (transpilation ES6/ES7, préprocesseurs CSS, hot reloading, composants monofichiers, alertes de sécurité et redémarrage à la volée du serveur, etc.).
Structure de projet
Si vous ouvrez le projet dans votre éditeur préféré, vous découvrirez que de nombreux dossiers ont été créés. Il faut savoir, comme dit plus haut, que toute la magie de Nuxt.js provient de l’analyse de ces différents dossiers et des fichiers qui les constituent. À l’image d’Ember.js, un autre framework assez apprécié chez Synbioz, celui-ci est régi par la règle « convention over configuration ». Il ne faudra donc pas modifier cette structure.
Regardons ça de plus près :
- Assets : contiendra nos fichiers SASS ou JavaScript non compilés
- Components : contiendra nos composants Vue
- Layouts : contiendra nos gabarits de pages
- Middleware : contiendra des fonctions à lancer avant le rendu de nos pages
- Pages : chaque fichier
.vue
de ce dossier générera automatiquement la route éponyme. - Plugins : contiendra les plugins à instancier avant l’application Vue (ex. : axios pour les requêtes HTTP)
- Static : contiendra nos fichiers statiques qui seront mappés à la racine de notre application (ex. :
sitemap.xml
) - Store : contiendra notre store Vuex (optionnel)
Configuration
Niveau outillage, Nuxt.js utilise Webpack et Babel mais, je vous rassure tout de suite, vous affranchit des longues heures de modification de webpack.config.js
et autres joyeusetés. Encore une fois, les créateurs ont tout fait pour que l’on puisse se concentrer sur l’essentiel : la réalisation de composants Vue. Un fichier nuxt.config.js
, très lisible et prérempli, permet malgré tout quelques réglages liés aux comportements par défaut de nos routes et au mode de déploiement désiré.
Comment ça marche ?
Nuxt.js ne requiert pas de définir explicitement nos routes dans un fichier spécifique. Il va les générer automatiquement en observant les fichiers du dossier /pages
.
Par exemple, si nous désirons rendre accessibles ces trois routes :
- /
- /posts
- /posts/1
Nous devons créer ces fichiers :
- /pages/index.vue
- /pages/posts/index.vue
- /pages/posts/_id.vue
Le framework gère à la fois les routes simples, dynamiques et imbriquées.
Comme on peut le voir sur ce schéma, voici ce qu’il se déroule lorsque l’on arrive sur l’application ou que l’on navigue dans celle-ci par l’intermédiaire des <nuxt-link>
, utilisés en lieu et place des <router-link>
proposés par vue-router :
- Suite à une requête HTTP, l’action
nuxtServerInit
du store est émise afin de le remplir avec des données issues du serveur, par exemple l’utilisateur authentifié et disponible en session - Puis vient le temps d’exécuter dans cet ordre de priorité, les middlewares définis dans le
nuxt.config.js
, le fichier de layout puis le fichier de page - Dans le cas d’une route dynamique, la méthode
validate()
des pages s’assure de sa conformité - Les méthodes
asyncData()
etfetch()
des pages vont respectivement récupérer les données et les fournir au store - Nuxt.js génère le rendu issu de l’imbrication d’un composant de layout et de composants de page (voir ci-dessous)
Déploiement
Une fois notre application terminée, Nuxt.js permet de la déployer de trois manières différentes et tout ceci sans avoir à modifier quoi que ce soit dans notre code !
Pour compiler une application isomorphique, nous utiliserons la commande npm run build
. Les vues seront donc rendues côté serveur avec les bénéfices évoqués au début de ce billet.
Si, pour une raison que vous préférez garder secrète, vous désirez ne pas profiter du rendu côté serveur et déployer une SPA classique, la commande npm run build --spa
est faite pour vous.
Cerise sur le gâteau, Nuxt.js propose, à la manière de Jekyll ou Middleman et via la commande npm generate
, de générer une application statique. Il vous restera à héberger le dossier /dist
sur votre CDN préféré, et pourquoi pas mettre en place une mise à jour automatisée grâce à un service comme AWS Lambda.
Conclusion
En à peine un an, Nuxt.js a su tirer son épingle du jeu et montrer des qualités indéniables. Si cette introduction vous a mis en appétit, je ne saurais trop vous conseiller de vous attarder sur l’awesome list du projet. Si vous avez un retour d’expérience sur l’utilisation de ce framework, n’hésitez pas à le partager avec nous !