La présentation de NuxtJS au VueJS Amsterdam 🔍

Pendant la conférence VueJS qui se tenait à Amsterdam le 16 février dernier, nous y avons découvert un framework JS innovant qui se positionne comme une surcouche à VueJS : il s’agit de NuxtJS.

Ce framework open-source disponible sur Github, se veut être une solution facilitant le développement d’applications VueJS rendues côté serveur (ou SSR pour Server-Side-Rendering).

Un de ses auteurs, Sébastien Chopin, speaker lors de la conférence, nous lprésente son framework et annonce la sortie récente de la phase de bêta avec une version 1.0 depuis le 8 janvier.

View this post on Instagram

Antonin & Baptiste étaient à #Amsterdam il y a peu, pour le #vuejsamsterdam 👍🏻 Merci à eux pour ce super #selfie ! 😎 #Webagency #Amsterdam #tshirtandgo #kaliopteam

A post shared by Kaliop (@kalioplive) on Apr 6, 2018 at 5:56am PDT

Avec maintenant plus de 10K stars sur Github, environ 100K téléchargements sur NPM et une version 1.4 à ce jour, découvrons ce framework afin de voir s’il tient ses promesses et s’il aide vraiment le développements d’applications.

La première chose à dire avant de commencer est l’effort qui a été fourni au niveau de la documentation avec :

• Un guide complet des différentes fonctionnalités
• Une description de l’API qui est fournie
• Des exemples de code pour chaque fonctionnalité
• Et même une FAQ

Cela permet de très facilement commencer le développement de votre application avec Nuxt.

Let’s get started !

🔥🔥 YESSSSS!! 🔥🔥 @_achopin Alexandre Chopin – Speed up your #Vuejs development time with #Nuxt ONLINE NOW: https://t.co/IJcpHwJ6tM #vue #javascript #vuejsamsterdam pic.twitter.com/X9MBJ5JFs9

— vuejs.amsterdam (@vuejsamsterdam) 2 mars 2018

A l’instar de l’installation d’un projet VueJS avec Webpack, il est facile de mettre en place une nouvelle instance de Nuxt. Celle-ci s’installe avec la vue-cli et utilise un boilerplate.
Comparons l’architecture d’une installation fraîche Nuxt à celle d’une instance Vue :

Nuxt

$ tree -L 2
.
├── assets
│   └── README.md
├── components
│   ├── AppLogo.vue
│   └── README.md
├── layouts
│   ├── default.vue
│   └── README.md
├── middleware
│   └── README.md
├── nuxt.config.js
├── package.json
├── package-lock.json
├── pages
│   ├── index.vue
│   └── README.md
├── plugins
│   └── README.md
├── README.md
├── static
│   ├── favicon.ico
│   └── README.md
└── store
    └── README.md
└── store

Vue

$ tree . -L 2
.
├── build
│   ├── build.js
│   ├── check-versions.js
│   ├── logo.png
│   ├── utils.js
│   ├── vue-loader.conf.js
│   ├── webpack.base.conf.js
│   ├── webpack.dev.conf.js
│   └── webpack.prod.conf.js
├── config
│   ├── dev.env.js
│   ├── index.js
│   ├── prod.env.js
│   └── test.env.js
├── index.html
├── package.json
├── package-lock.json
├── README.md
├── src
│   ├── App.vue
│   ├── assets
│   ├── components
│   ├── main.js
│   └── router
└── static

On y retrouve des différences, notamment sur les dossiers “layouts”, “middleware”, “pages” et “plugins”. Attardons nous sur le dossier “pages” dans un premier temps.

Ecrire le routeur dans un fichier… HAS BEEN?

Nuxt fournit une surcouche au routeur natif de vue qui permet de générer des routes en fonction des fichiers présents dans le dossier.

Il n’est plus nécessaire d’avoir à gérer un fichier “index.js” du routeur natif pour créer ses routes et devoir importer ses composants.

Le nom du fichier est directement utilisé comme nom de route et le composant présent sera utilisé comme point d’entrée. Il est toujours possible de créer des routes “enfants” ainsi que de créer des routes dynamiques.

Admettons que vous voulez construire votre portfolio de développeur. Vous voulez :

• Afficher votre homepage
• Un showcase pour chacune des compétences que vous avez
• Une page de contact

Vous pouvez imaginer une organisation suivante de vos fichiers :

pages/
├── contact.vue
├── index.vue
└── skills
    ├── index.vue
    ├── javascript.vue
    └── nodejs.vue

Chaque fichier “index.vue” est utilisé comme racine. Vous vous retrouverez donc avec une architecture de routing équivalente à ça :

router: {
  routes: [
    {
      name: 'index',
      path: '/',
      component: 'pages/index.vue'
    },
    {
      name: 'contact',
      path: '/contact',
      component: 'pages/contact.vue'
    },
    {
      name: ‘skills',
      path: '/skills,
      component: 'pages/skills/index.vue'
    },
    {
      name: ‘javascript,
      path: '/skills/javascript,
      component: 'pages/skills/javascript.vue'
    },
    {
      name: ‘nodejs',
      path: '/skills/nodejs,
      component: 'pages/skills/nodejs.vue'
    },
  ]
}

Ok, mais les routes dynamiques?

La présence d’un underscore dans le nom du fichier sera interprété comme une route dynamique :

pages
├── index.vue
└── users
    └── _id.vue

router: {
  routes: [
    {
      name: 'index',
      path: '/',
      component: 'pages/index.vue'
    },
    {
      name: 'users-id',
      path: '/users/:id?',
      component: 'pages/users/_id.vue'
    }
  ]
}

D’autres cas sont gérés, tels que les routes enfants d’une autre route, de façon dynamique ou non. Cette façon de définir des routes amène une autre approche à la création de routes, vous n’avez plus à gérer de fichier de configuration de routes. Cependant, cela injecte un “niveau de magie”.

Là, normalement, si vous avez beaucoup utilisé Vue, vous vous demandez une chose :

Mais où est Charl… où sont les navigations guards ?

C’est là qu’entre en jeu les MiddleWares.

Les MiddleWares

Définition : “Un Middleware permet de définir une fonction personnalisée qui sera exécutée avant le rendu d’une page ou d’un groupe de pages”. 

Il nous permet donc de faire nos propre naviguations guards. D’autres applications peuvent être imputées aux MiddleWares, comme la gestion de statistiques ou le chargement d’un store sur certaines pages spécifiques, par exemple.

A savoir que le code d’un middleware a la connaissance de son contexte. Il est donc possible d’exécuter des actions seulement coté serveur.

Plutôt sympa, non ?
Plus besoin de définir dans votre fichier de router, un naviguation guard “beforeEach” pour faire vos actions entre chaque page !

Si on résume, nous avons vu l’architecture d’une application Nuxt, la création d’une architecture de pages avec la mise en place des composants spécialement pour le SSR et l’exécution de code entre deux pages. Il manque donc l’initialisation de notre application : l’utilisation de plugins.

Des plugins ? Pas au sens que l’on attend

Il s’agit de code Javascript exécuté avant l’instantiation de l’application. Si nous faisons le comparatif avec une instance classique Vue, c’est en créant un (ou plusieurs) plugin(s), qu’il est possible de reproduire le comportement du fichier “main.js” qui permet d’instancier des vendors tels que le “vue-i18n” ou “vue-notifications”.
Toujours dans le contexte du SSR, il est possible d’exécuter des plugins limités au scope client, afin de pouvoir utiliser des librairies qui ne supportent pas le SSR.

Ok.. Mais, c’est quoi une librairie qui ne supporte pas le SSR ?

C’est une librairie qui, par exemple, s’appuie sur l’objet window pour s’initialiser. L’objet window n’est pas disponible dans un contexte SSR.

A mon sens, l’avantage de ce système de plugins est de définir un plugin pour chaque vendor utilisé et de pouvoir faire l’initialisation de ces plugins en fonction du contexte.

Plus besoin d’avoir un fichier d’entrée qui grossit au fur et à mesure de la vie de votre application.

Passons à la prod’ !

Pour finir, Nuxt propose différents modes pour la production :

• En mode SSR : Un serveur NodeJS est utilisé pour générer l’application et la servir directement au client.
• En mode “SPA” : Nuxt utilise l’appellation “SPA” pour un mode bien précis. Le framework profite de l’organisation des fichiers de l’application par pages pour effectuer du pré-rendering pendant la phase de build. Le client aura donc directement le HTML de l’application, afin de palier aux problématiques SEO, sans avoir un serveur NodeJS qui rend l’application dans un contexte où il n’est pas possible de faire du SSR.
• En mode “Statique” : Il s’agit d’une génération classique d’un fichier VueJS qui n’aura aucun HTML présent lors du chargement de l’application

I am Nuxt !

Ce framework propose de nombreuses fonctionnalités qui permettent de faciliter le développement d’applications VueJS. La principale, et non des moindre, est la gestion “out of the box” du server side rendering, qui permet très facilement de résoudre la problématique de SEO (qu’amène les applications SPA).

Les différents modes de production permettent de couvrir les besoins réels de votre projet.

Bien que cet article ne couvre pas l’intégralité des atouts de Nuxt, d’autres fonctionnalités telles que les middlewares, layouts, la gestion du store, le composant “no-ssr” et la récupération d’informations avant le rendu du composant sont aussi disponibles.

Une version 2.0 est déjà en train de voir le jour, ce qui prouve la grande activité et de l’engouement autour de ce projet communautaire Vue.

Le développement d’une application se révèle être facile et efficace.

Le framework se charge de la configuration pour vous, vous laissant encore plus de place au développement ! Pour moi, le contrat proposé est entièrement rempli et je peux dire que mon side-project sera avec Nuxt !

Il me reste une chose à vous demander : Are you Nuxt?!

Pour aller plus loin

Vous pouvez retrouver la conférence d’Alexandre Chopin, l’un des auteurs :

De la lecture :

• Le guide de Nuxt (EN)
• GitHub Nuxt/Nuxt.js
• Article (EN) : Nuxt 2 is coming