À l'usage je trouve que le saut du curseur sur le champ de recherche
d'entreprise est perturbant. Je pense que ça pose aussi des problèmes
d'accessibilité (navigation au clavier, lecteur d'écran), en particulier
pour la page d'accueil.
https://developer.mozilla.org/fr/docs/Web/HTML/Global_attributes/autofocus#remarques_sur_laccessibilit%C3%A9_de_la_fonctionnalit%C3%A9
Google met bien de l'autofocus sur sa page d'accueil mais le champ
de recherche est vraiment ce que la personne va utiliser à 99%, ce qui
n'est pas le cas pour nous.
- Creation d'un composnant <BrowserOnly /> pour éviter le CLS
- Restaure l'animation de chargement et le message de navigateur obsolète
- Correction d'une chaîne de caractère dans l'UI avec des tabulations
- Répare la section nouveautés
- Suppression du rehooks/local-storage
- Suppression de swr
Désormais nous utilisons un script NodeJS natif pour générer le code
HTML pour le pré-rendu des pages. Cela est plus rapide et plus fiable
que la méthode précédente qui consistait un instrumentaliser un
navigateur (pupetter)
https://github.com/chrisvfritz/prerender-spa-plugin
Cela implique toutefois de faire attention à ne plus utiliser des
variables gloables du navigateur, comme `window`, `document` ou
`location` dans nos scripts. C'est plutôt une bonne pratique, mais il
faudrait sans doute configurer du typage pour détecter ces usages le
plus tôt possible et éviter de créer des erreurs inopinées avec le SSR.
La version utilisée de react-markdown n'était pas compatible avec
ViteJS. J'ai tenté la mise à jour vers la v7 qui est publiée sous forme
de ES Module, ce qui nécessitait d'intégrer plusieurs changements d'API.
En m'y attelant j'ai réalisé que la motivation première de
react-markdown était de ne surtout pas utiliser
`dangerouslySetInnerHTML`, ce qui est utile pour les cas d'usages où le
markdown n'est pas digne de confiance (message d'utilisateurs par
exemple). Cette contrainte oblige à alourdir sensiblement la quantité de
JavaScript à charger et à évaluer.
Anisi dans certains markdown que l'on affiche, on utilise la balise HTML
`<sup>`, qui n'est pas parsée nativement pas react-markdown. Comme on ne
peut pas faire de `dangerouslySetInnerHTML` il faut intégrer un parseur
HTML complet qui rajout 60kb, juste pour quelques occurences de `<sup>`
dans les pages nouveautés.
Dans notre cas d'usage reparser tout le html en Javascript, n'est pas
utile. markdown-to-jsx semble plus adapté et beaucoup plus léger. Par
ailleurs le paquet est 5 fois plus utilisé que react-markdown :
https://www.npmtrends.com/react-markdown-vs-markdown-to-jsx
- Création d'un plugin personnalisé pour gérer le serveur dev et le
build Rollup
- Restauration d'un template.html (ne fonctionne pas encore au build)
- Suppression de la config Babel
Nous utilisions Jest uniquement pour les tests de non regressions qui
recquièrent le “snapshot testing”. Cette fonctionnalité étant supoprtée
par Vitest, il n'est plus utile de maintenir 2 environnement de tests
séparés.
Réactive 2 suites de tests qui n'étaient plus fonctionnelles :
- les "exemples" définis directements dans le publicodes
- le StackedBarChart
Suppression de mocha, mochapack, sinon, chai
Avec vite, on n'utilise plus `process.env` côté client, mais
`import.meta.env`. Par ailleurs seules les variables d'environnement
préfixées par `VITE_` sont exposées au client, les autres sont
uniquement disponibles côté serveur.
Maxime Quandalle
Jérémy Rialland
Johan Girod