Améliore la gestion des requêtes

Contexte

Ref: https://datahub.incubateur.tech/infrastructure/indicateurs/-/issues/166

Une PR relativement conséquente avec initialement l'idée d'améliorer la gestion des requêtes de notre app, et au final les changements suivants:

• Caching des requêtes via la combinaison id d'indicateur, maille, code (le cache est uniquement en mémoire, pour améliorer le chargement ultérieur d'une page déjà visitée)
• Retry des requêtes 3x à 300ms d'intervalle (c'est configurable si besoin), uniquement pour les erreurs >= 500
• Gestion des états de chargements: un indicateur individuel est ajouté au niveau de chaque indicateur (de type "skeleton", voir videos ci-dessous)
• Gestion des erreurs: basé sur ce design suite à discussions avec Aurélie, un peu plus de détails ci-dessous.
• Ajout de headers afin d'identifier les requêtes provenant de notre app ainsi que la version

Note: pour le moment pas de batching des requêtes, c'est quelque chose que nous pourrons étudier dans une future fonctionnalité si ça semble pertinent.

Contenu

Plusieurs choix ont été faits, le principal étant l'ajout de react-query pour nous aider dans la gestion générale des requêtes, c'est une librairie plutôt légère et qui offre pas mal de fonctionnalités pour nous simplifier les choses, notamment un cache, une gestion des retry, et la possibilité d'inspecter l'état des requêtes.

La librairie ne gère pas le batching contrairement à apollo-client qui a été une option étudiée aussi, mais ça ne nous semblait pas être la fonctionnalité la plus importante, et le poids et la difficulté de mise en place d'apollo-client a fait pencher la balance en faveur de react-query.

Quelques sections pour détailler les choix pour les fonctionnalités:

Etats de chargement

Après échanges et tests, on a décidé de laisser uniquement une vue de type skeleton pour les indicateurs en train de charger. La logique est donc très simple, il n y a aucune question de centralisation des états de chargements (même si l'info est disponible via GlobalQueryTrackerContext si on décide de changer cet aspect).

Gestion d'erreur

Pour la gestion d'erreurs, nous avons donc les partis pris suivants:

• Une erreur "globale" affichée en haut de la page dès lors que nous avons au moins une erreur >= 500 (après retry)
• Dans ce cas, aucune autre erreur n'est affichée dans la page et les indicateurs restent "vides" (cf design figma)
• Au niveau des catégories, nous "trackons" les erreurs des indicateurs enfants, si nous avons > 1 erreur, nous affichons une seule erreur (avec l'indicateur d'alerte rouge)
• Si un indicateur individuel est en erreur et qu'il n y a pas d'erreur parente affichée (au niveau de la page ou de la catégorie), on affiche l'alerte d'erreur rouge également

A noter que ces cas d'erreur au niveau indicateur seront probablement très rares.

Headers (pour sentry)

Nous avions discuté de la possibilité d'ajouter des headers à nos requêtes pour identifier notre application fiches - c'est chose faite dans cette PR, cf abd741a3.

J'ai rajouté x-client-name et x-client-version. Pour le hash de commit j'utilise une variable gitlab CI et je ne sais pas si ça va fonctionner, on va dire que c'est un test pour le moment 😅

Testing

Pour tester la vue de chargement de données, on peut simuler du délai en ajoutant à queryFn dans hooks/useFetchIndicateur.ts une ligne de type await new Promise((res) => setTimeout(res, 1000));

Pour tester les erreurs de connectivité, une possibilité est de changer l'URL NEXT_PUBLIC_INDICATEURS_URL pour http://httpstat.us/502 qui permet de tester différents status network.

Screenshots / vidéos

Loading

skeleton_fiches

Erreurs

Erreur globale (network):

Erreur localisée (catégorie):