* 🐛🎨 Fix des élements qui apparaisent à l'impression
* 🐛🎨 Fix des block vide à l'impression
* 🐛🎨 Fix des types
* 🐛💻 Ajout d'un check pour afficher le bouton d'impression
* 🐛🎨 Fix des types
* 🐛🎨 Amélioration visuel lors de l'impression
* 🐛🎨 Suppression des marges autour du simulateur à l'impression
* 🐛🎨 Supression d'une classe global css inutile
* ✨ Fix types
* 🏓🤩 Ajout d'un selecteur de période sur les simulateurs indépendants
Amélioration du type Simulation
fix#1138
* 🏓🤩 Fix pour que la traduction puisse fonctionner
* 🏓🤩 Fix de la traduction
Affichage du status que deepl retourne en cas d'erreur
* ✨ Refacto du selecteur d'année
🎨 Ajout du selecteur d'année sur le simulateur auto-entrepreneur
🔥 Suppression du lien vers l'aide à la déclaration des revenus
🎨 Ajout de l'année dans le titre du simulateur
* 🐛 Ajout des var d'env dans le template
🐛 Fix d'un process.env restant
* 🐛 Fix des fakeData
* 👽 Fix traduction
* ✨ Refacto du selecteur d'année
👽 Fix traduction
* ✨ Refacto de la config eslint
* ✨ Ajout de rel='noreferrer' sur les liens
* ✨ Fix de différentes erreurs de types et de tests
* ✨ Ajout des regles cypress dans eslint
* ✨ Suppression de la regle react/jsx-no-target-blank
* ✨ Fix import
À 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
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.
Johan Girod
Jérémy Rialland
Maxime Quandalle
Alexandre Valsamou-Stanislawski
Alexandre Hajjar