#2 - Nuxt.js, l'art de la composition, accessibilité : retour de la Vue.js Amsterdam 2023

Pour la première fois, Wanadev s’est rendu à la plus grosse conférence annuelle autour de Vue.js : la Vue.js Amsterdam 2023. J’ai eu l’honneur d’assister à la 5ème édition, couronnée par le retour d’Evan You, le créateur de Vue.js et Vite, en personne.

Dans cette série de quatre articles, je vais vous faire revivre ces deux jours de conférences. En les lisant, vous aurez l’impression d’y avoir assisté !

Cet article est le second des quatre, vous pourrez retrouver chaque partie de cette série ici :

• Partie 1
• Partie 2
• Partie 3
• Partie 4

Dans cet article on va parler de Nuxt en 2023, d’un client Mastodon fait avec Nuxt, d’expérience développeur sur Nuxt, de Nitropack, de CSS-in-TS, de comment concevoir ses composants Vue.js, d’accessibilité et de maintenance d’écosystème open-source en entreprise.

Beaucoup de sujets à traiter, alors c’est parti !

State of Nuxt 2023 - Sébastien Chopin (Replay)

Sébastien Chopin, le créateur de Nuxt, nous fait un point sur ce qu'on peut attendre en 2023 pour Nuxt, le framework pour faire du rendu serveur avec Vue.js.

Tout d’abord, un peu de contexte :

• Nuxt c'est 2 millions de téléchargements par mois : 72% pour sa version 2 et 28% en version 3.
• En comparaison, Vue c'est 15 millions de téléchargements par mois : 65% en Vue 2 et 35% en Vue 3.

Les fonctionnalités de Nuxt sont nombreuses : SSR / CSR / SSG / ESR / Hooks / FS Router / Auto Imports / Data Fetching / Middleware / Plugins / Layouts / Transitions / Server API / TypeScript / State Management / Island Components / Layers / Pre-processors / Modules / SEO Helpers / Testing / PostCSS / etc.

Beaucoup de jargon technique, mais, si vous souhaitez en savoir plus, je vous invite à vous rendre sur la documentation de Nuxt qui est excellente d’ailleurs !

Pour 2023, les objectifs sont multiples :

• atteindre 51% d'utilisation de Nuxt 3
• travailler sur Nuxt Bridge pour aider à la migration des gros projets tout en proposant des workshops
• améliorer l'expérience développeur (voir plus loin dans l’article)
• avoir plus qu'un seul site web (actuellement on en a un pour la V2 et un pour la V3).

Pour les releases :

• une majeure tous les ans avec moins de Breaking Changes.
• une mineure tous les mois.
• un patch toutes les semaines.

Prochainement :

• fetch des données en parallèle
• rendu hybride
• pages en markdown
• édition de markdown

Elk : développer rapidement avec Nuxt 3 - Daniel Roe (Replay)

Elk c'est un client web pour Mastodon, le réseau social décentralisé, qui a été conçu avec Nuxt 3 par 4 personnes dont Daniel Roe.

Grâce à Nuxt 3 ce client de Mastodon a été développé très rapidement avec :

• développement rapide grâce aux modules
• hybride serverless grâce à unjs/nitro
• contextes empilables
• configuration au runtime
• Key/Value storage
• tests unitaires
• web push notifications
• PWA supporté
• applications natives
• i18n

Pour en savoir plus : https://github.com/elk-zone/elk

Nuxt et son expérience développeur - Anthony Fu (Replay)

Anthony Fu, membre de la core team de Vue.js, Vite et Nuxt, mais aussi créateur de VueUse, Vitest, UnoCSS et de beaucoup d’autres projets est un giga crack. Il nous présente ce qu'il fait pour améliorer l'expérience des développeurs dans l'écosystème Vue.

En améliorant la réactivité (on modifie le code, ça modifie l’interface) :

• Côté client grâce à Vite
• Côté serveur grâce à vite-node
• Côté API grâce à Nitro

En respectant les meilleures pratiques :

• TypeScript / ESM
• SPA / SSR / Static / Hybrid
• Layout / Plugin / Route middlewares / etc.
• composables : useState, useAsyncData, useFetch, etc.
• Head/SEO : useHead, useSeoMeta, etc.
• backend intégration, serverless, etc.

En respectant les conventions :

• Routing basé sur les fichiers
• API basés sur les fichiers
• composants auto importés
• composables auto importés
• composants uniquement pour le client / serveur
• typage de bout en bout

En développant l’écosystème :

• modules
• intégration sans effort

Il reste un problème :

• l'abstraction crée de la complexité à la compréhension
• les conventions peuvent être implicites
• ça peut être dur à debug

Il existe une solution pour cela vite-plugin-inspect qui permet d’inspecter les états intermédiaires de vite.

Mais, pour les développeurs de Nuxt, il y a désormais beaucoup mieux et il s’agit de Nuxt Dev Tools.

Annoncé lors de la conférence et mis en public en direct sur scène, cet outil cherche à :

• améliorer l'expérience développeur sur Nuxt
• être transparent sur les conventions
• fournir des analyses et des données de performance
• être interactif et joueur
• fournir de la documentation personnalisée

S'en est suivie une démonstration qui nous a permis de voir la puissance de Nuxt DevTools qui est encore dans sa phase bêta:

• retrouver toutes les pages de son application à un seul endroit
• lister et naviguer au sein de tous les composants
• afficher un graph des relations entre les composants
• débug sur l’auto import
• savoir d'où viennent les imports et combien de fois ils sont utilisés
• pour les modules : savoir lesquels sont utilisés et prochainement un bouton pour installer un module directement depuis le Dev Tools
• pouvoir changer l'état de l'app depuis le Dev Tools
• et pleins d'autres choses à découvrir dans le DevTools

UnJS: Nitropack - Pooya Parsa (Replay)

Né en novembre 2020, Nitro est un framework qui permet de créer un web serveur en JavaScript performant avec du typage et qui fonctionne en harmonie avec Nuxt 3.

Le but :

• écrire moins de code et livrer plus
• proposer une meilleure expérience développeur
• avoir plus d'options et donc plus de polyvalence.

Web Platform Standards :

• compatible avec Cloudflare Workers, Deno et Bun.
• on ne perd rien de l'écosystème NPM.

Nitro fournit une couche d'abstraction avec différentes fonctionnalités :

• ajouter des règles sur les routes (caching, redirect, header, render strategy, etc.)
• gérer du cache (Stale While Revalidate)
• Key/Value Storage Layer
• Static Asset et support du rendu serveur natif
• routing et routes d’API

Les performances sont imbattables grâce à la stratégie de mise en cache (Stale While Revalidate) : un temps de réponse qui est 5 à 1500 fois plus rapide !

Comment fonctionne la stratégie Stale While Revalidate ?

Nouveautés dans Nitro et Nuxt :

• support du stockage de binaire
• support des sessions
• runtime proxy
• event context and fetching
• composables auto importés (utils/composables)
• node_modules traceur optimisé pour le bundle de sortie
• nitro pod format

La roadmap pour 2023 :

• une nouvelle CLI
• websocket
• logging et timing API
• auto génération de documentation / OpenAPI pour les routes de l’API
• fonctions côté serveur
• des healthchecks et preflight checks automatisés

Slides : https://docs.google.com/presentation/d/1SQwc3KO200DKufHE5hzbGn8dg06Z9j9b-ng3SH8ILUo/edit

Pinceau : CSS-in-JS avec Vue - Yaël Guilloux (Replay)

Grâce à Vue Teslescope, une extension de navigateur qui donne des informations sur quel framework, quelle librairie CSS ou de composants le site utilise, on sait que plus de 50% des applications en Nuxt 3 et 25% des apps en Vue 3 utilisent des frameworks CSS.

Après nous avoir raconté l'histoire de comment est né Pinceau, on apprend les sources d'inspiration de cette nouvelle librairie :

• Stitches
• Vanilla Extract
• UnoCSS

S'en est suivie une démonstration sur comment ça fonctionne en pratique :

• comment créer son thème : media queries & responsive tokens, propriétés utilitaires, ...
• comment styliser ses composants : css() fonctions, computed styles, variants, performances et SSR, ....

Globalement, la force de pinceau est qu'on peut faire du TypeScript dans la balise style de son composant et donc avoir des erreurs de typage dans le cas où on utilise une propriété inexistante.

L'art de la visualisation et de la composition pour construire ses composants - Maya Shavin (Replay)

Deux éléments apparaissent quand on souhaite créer un composant Vue.js :

• l'extensibilité (processus interne) : ajouter des fonctionnalités. Si on prend comme exemple celui d'une galerie de pizzas, ça reviendrait à ajouter un panier, afficher une liste, ajouter un champ de recherche, une liste de favoris, etc.
• la réutilisabilité (processus externe) : gérer d'autres APIs, nouvelles langues, etc.

On peut ajouter plus de props et refactor ou PLANIFIER SON COMPOSANT AVEC LA COMPOSITION !

La c'est 3 points importants :

• dépendance externe : dans cet exemple, un composable useFetchData est créé.

• flexibilité : l’utilisation des slots permet de simplifier son composant.

• partage : à l’aide d’un composant FetchComponent et Items, on peut aller encore plus loin dans le partage de fonctionnalités.

Dans le cas de notre galerie de pizza, où on devrait ajouter une liste à notre galerie, une recherche, un panier, une notion de liste de favoris, on aurait le système de composables et composants suivant :

Les avantages et inconvénients d'un tel système sont les suivants :

La composition n'est pas la seule méthode pour construire ses composants, on parle aussi de la visualisation, mais qu'est-ce que c'est ?

Eh bien, c'est le fait de pouvoir visualiser la logique de son application. On peut par exemple utiliser stately pour cela !

Pour le cas d'un processus de validation de commande, on aurait plusieurs états à visualiser : facturation / livraison / paiement / confirmation. Et les différentes interactions entre ces états.

En résumé :

• Planifier son composant d'abord et coder plus tard.
• Visualiser la logique de son application dès que possible.
• Séparer la logique de l'affichage quand c'est possible.
• La composition est flexible, mais elle demande de l'apprentissage et de la planification.
• La composition peut être inadaptée si un design system strict est nécessaire.

Prévenir, détecter et corriger les problèmes d'accessibilité - Maria Lamardo (Replay)

Après ce rappel : 1 personne sur 6 a un handicap (16% de la population selon l'Organisation Mondiale de la Santé).

En prenant l’exemple de plusieurs designs d’escaliers, Maria Lamardo montre que l’accessibilité dans le monde numérique a des problématiques communes avec le monde réel.

Dans le monde numérique, il faut comprendre l'expérience qu’ont nos utilisateurs lorsqu’ils utilisent notre site web :

1. comment les personnes naviguent au sein du contenu.
2. inclure les personnes avec des handicaps dans le processus.
3. considérer l'impact des décisions de conception sur ces expériences.
4. utiliser les résultats pour construire des expériences accessibles.

Il y a plusieurs types de handicaps et, selon ces handicaps, on n'accède pas au contenu numérique de la même façon :

• handicap moteur : reconnaissance vocale par exemple.
• handicap visuel : lecteur d’écran par exemple.
• handicap auditif : logiciel de transcription par exemple.
• cognitif : aides cognitives par exemple.

L'accessibilité du numérique est importante, c'est d’ailleurs un des principes fondateurs d'Internet !

Pour qu’elle soit prise en considération, l’accessibilité doit s'inscrire tout au long du cycle de vie du développement logiciel : planification > design > implémentation > test > maintenance.

Un bon outil partagé pour tester l'accessibilité d’un site web est celui d'IBM disponible sur GitHub.

Ensuite, on parle des problèmes récurrents d'accessibilité rapportés par WebAIM Million, sachant que 96,8% des pages d'accueil ont des problèmes d'accessibilité et qu'il y a environ 50,8 erreurs par page, la plupart sont :

1. Le contraste faible du texte
2. Un texte alternatif manquant
3. Des liens vides
4. Des libellés de champs de formulaire manquants
5. Des boutons vides
6. La langue du document manquante

Pour éviter ces erreurs d'accessibilité, il faut vérifier ces 4 grands principes :

1. Perceptible : tout doit être perçu
   • faible contraste de couleur
   • texte alternatif manquant
   • des images significatives
   • des images décoratives
   • des problèmes avec les indicateurs visuels
2. Utilisable : navigable au clavier
   • liens vides
   • des libellés de champs de formulaire manquants
   • des problèmes avec la hiérarchie des titres
   • la navigabilité au clavier
3. Compréhensible
   • langue du document manquante
4. Robuste
   • boutons vides
   • attributs ARIA manquants

Retrouvez les slides ici : https://docs.google.com/presentation/d/1KLC5mkAnyptaLQB9Ou29zqLXJtEiiCXUnUMGjIe4apE/edit#slide=id.g18216de4e5a_0_1085

Maintenir l'écosystème open-source de son entreprise - Lucie Haberer (Replay)

Package écosystème

• Qu'est-ce qu'un écosystème de packages ?

"A package ecosystem is all the packages under the responsibility of an entity, whether it's an individual, a company, etc."

Il peut être privé ou public. Il peut comporter un seul package.

Pourquoi créer un package ?

• Pour abstraire certaines parties : attention à ne pas abstraire prématurément.
• Pour forker des packages existants.
• Pour créer une nouvelle technologie.

On crée des packages pour améliorer notre développement et rendre nos logiciels plus forts.

Comment les packages fonctionnent ?

• PHP packages
• Deno modules
• Rust crates
• Ruby gems
• ...

Chacun a son propre fonctionnement. Pour le JS, ce sont les packages npm !

NPM c'est :

• ... une CLI (tout comme yarn, pnpm, etc.)
• ... mais aussi une base de données en ligne : un registre où les packages peuvent être publiés et téléchargés (mais vous pouvez aussi avoir votre propre registre).

package.json : 2 champs sont obligatoires :

• le champ name pour donner le nom du package et peut être scopé (@wanadev/ma-super-lib par exemple, mais il faut évidemment avoir les accès au scop !)
• version qui doit respecter SemVer, une convention qui permet de refléter les types de changements entre 2 versions.

Un package sert à délivrer du code, d’où la présence d’entrypoints :

• main pour ESM.
• module pour CommonJS.
• exports : plus moderne pour spécifier ESM (import) et CommonJS (require)

=> utiliser les 3 pour être compatible avec le plus d'environnements possibles !

Ensuite, il y a d'autres champs dans package.json, comme :

• types pour fonctionnement avec TypeScript.
• fields pour livrer des images ou tout autre fichier.

Types de dépendances :

• dependencies : requises pour démarrer le package.
• devDependencies : requires pour compiler le package.
• peerDependencies : requises si le package dépend d'un autre pour fonctionner.

Pour aller plus loin, il y a la documentation : https://docs.npmjs.com/cli/v9/configuring-npm/package-json

Maintenance des packages

• les gens ont beaucoup d'attente envers les packages open-source : c'est ok si on ne supporte pas TypeScript, et CJS et ESM, si on a pas de TSDocs, etc.

=> si le package fonctionne pour soi et d'autres c'est déjà super !

• s'inspirer des projets open-source des autres. On apprend énormément de cette façon.

=> s'amuser avec le dossier .github

=> automatiser le processus de release avec Standard Version CLI

=> mettre à jour ses dépendances avec des outils comme VSCode Version Lens

• Maintenance régulière :

=> corriger les bugs s'il y en a.

=> maintenir les dépendances : les mettre à jour !

Faire évoluer ses packages

• ajouter des petites fonctionnalités dès qu'elles arrivent
• planifier les grosses fonctionnalités et les breaking changes (les RFCs fonctionnent bien)

Un package peut aussi mourir, parce que ce qu'on a développé est désormais natif ou fait autre part d'une meilleure manière, et donc personne ne veut plus le maintenir. Pour cela, utilisez la commande npm deprecate !

Retrouvez les slides ici : https://230209-open-source-ecosystem.diapositiv.lihbr.com/1

Merci d’avoir lu ce résumé de la seconde partie du premier jour de la Vue.js Amsterdam 2023.

Vous trouverez la suite juste ici : Partie 3.