InseeFr / InseeFr/Lunatic

Mise à jour du "lastReachedPage" plus réactif

Open
#1,038 4 comments 0 reactions 0 assignees View on GitHub
need specs
Dominant language
TypeScript
Stars
22
Forks
21
Avg merge
9h 13m
Merged PRs (30d)
2

Description

## Contexte

`lastReachedPage` permet de mémoriser la dernière page atteinte dans un formulaire. Cette valeur est mis à jour dès que l'utilisateur dépasse le précédent `lastReachedPage` lors de la navigation.

## Problème

L'implémentation actuelle ne prévoit pas que cette valeur puisse décroître, ce qui pose des problèmes dans plusieurs situations :

- Si l'utilisateur change une réponse en amont qui révèle une nouvelle page entre la page courante et le `lastReachedPage`.
- Si l'utilisateur change une réponse en amont qui masque la page marquée par le `lastReachedPage`.
- Si l'utilisateur change une réponse qui change le nombre d'itération d'une boucle future :
- Si le `lastReachedPage` était sur une sous page de la boucle qui n'existe plus alors il doit avancer.
- Si une itération est ajoutée le `lastReachedPage` doit venir se placer au début de cette nouvelle itération.

Il y a donc plusieurs souci pour implémenter un `lastReachedPage` qui soit plus dynamique :

- Déterminer dans laquelle des 4 situations précédentes on se trouve lors d'un changement de valeur.
- Déterminer où il faut aller et surtout dans quelle direction faire évoluer le `lastReachedPage`.

## Idée 1 : page attendant une réponse

Une première idée exprimée par l'issue [#1026](https://github.com/InseeFr/Lunatic/issues/1026) est d'avoir un concept de "page avec réponse manquante" et de plutôt utiliser ce concept pour déterminer la dernière page atteinte par l'utilisateur. Cette solution possède malheureusement aussi des problème :

- On doit parcourir l'ensemble des pages à partir de la page courante à chaque changement de variable pour obtenir la valeur (calcul potentiellement lourd)
- Certains champs ne sont pas obligatoire mais on ne le sait pas nécessairement sans exécuter tous les conditionFilter / control. Le problème devient particulièrement complexe lors d'une boucle non paginée pour déterminer si elle attend une réponse ou non.

## Idée 2 : conditionFilter au niveau page

Une seconde idée serait d'associer à chaque page une condition d'affichage (comme un conditionFilter mais au niveau de la page). Avec cette approche on pourrait calculer plus facilement si une page est atteignable ou non. Cela implique tout de même d'avoir de nombreux calcul de fait à chaque changement de valeur de variables.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.