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
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.
On en profite pour faire un usage étendu des ancres en yaml. C'est pas
forcément très lisible, mais ça permet de répondre au problème de
la duplication des structures de données en publicodes.
Il faudrait éventuellement documenter cela sur la documentation officielle.
* 🎨 Ajoute un champs de recherche d'entreprise dans la page d'accueil
Aucune intéractivité ajoutée pour l'instant
🔥 Déplace la recherche dans un nouveau composant
🎨 Ajoute une animation lors de la saisie de texte
🎨✨ Branche la recherche d'entreprise via l'api existante
🎨 Améliorations diverses
✨ ajoute la possibilité d'utiliser entrée lorsqu'il n'y a qu'un seul résultat
Remplace les résultats sous forme de lien par des boutons
🐛 Fix le prérendu
💚 Fix TS & répare le composant 'Appear'
Améliore le style sur mobile
Ajoute une section simulateurs sur la landing
Enlève l'animation lorsqu'on revient à la page d'accueil depuis une autre page
Branche la selection d'entreprise avec la page 'gérer'
Branche la selection d'entreprise avec la page 'gérer'
Ajoute un raccourci vers l'entreprise selectionnée depuis la page d'accueil
👽 ajoute les traductions manquantes
* Adapte la nouvelle page à la charte URSSAF
* Répare la selection des resultats
Simplifie le contenu de la landing
* Met à jour les tests cypress avec le flow de recherche
* Répare les erreurs de type
* Réduit la taille du champ de recherche sur la landing
* Met en avant la recherche entreprise
* Améliore le test cypress de la recherche
* Utilise une couleur moins forte pour le fond de la recherche
* Remet en couleur claire par la landing
* Utilise data-testid pour identifier les éléments de la recherche
* Enlève un composant non utilisé
Co-authored-by: Johan Girod <johan.girod@beta.gouv.fr>
Co-authored-by: Alexandre Valsamou-Stanislawski <alexandre.valsamoustanislawski@beta.gouv.fr>