Pre remplissage de champs depuis un serveur

Grafikart commented 4 months ago

Problème

Dans le cadre de certaines enquêtes on aimerait pre-remplir les données du formulaire suite à la réponse à une question :

En page 1 on demande l'id du logement
En page 2 les champs de l'adresse sont pre-remplit avec les informations récupérées depuis le serveur

Pour obtenir les données entre les 2 pages une API serait contacté en POST avec la réponse à la question (ici l'id) et renverrai les données à injecter dans le formulaire (cette API serait public). Il faudra déterminer si les données renvoyées par le serveur peuvent écraser des données existantes.

Solutions

On va ici explorer les différentes solutions envisageables dans l'objectif de faire un choix technique et aussi de receuillir des idées.

Côté orchestrateur

La première solution est de laisser cette tâche à l'orchestrateur qui devra observer les variables qui changent et les changements de page et manuellement déclencher le handleChange lorsqu'il reçoit les données du serveur.

🟢 Pas de travail côté Lunatic
🔴 Le code n'est pas réutilisable
🔴 On pollue l'orchestrateur

Création d'un composant "RemoteComponent" avec enfant

On crée un composant particulier qui va être capable de récupérer les données et de conditionner l'affichage de composants enfant.

{
  "componentType": "RemoteComponent",
  "endpoint": {
    "url": "https://insee.fr/autocomplete/address",
    "data": "content.data"
  },
  "responses": [
    {"name": "ID"},
    {"name": "CODE"}
  ],
  "components": [
    {
      "componentType": "Input",
      ...
    }
  ]
}

Dès que ce composant est monté il contacte le serveur (en envoyant les données correspondant à "responses") pour obtenir les données à hydrater. Une fois la réponse obtenue les données sont passée à Lunatic et les composants enfants sont affichées

🟢 Approche réutilisable
🟢 On peut conditionner l'affichage des sous composants
🔴 On ne peut remplir que les composants enfants
🔴 La présence de sous composant complexifie l'arbre (pour la recherche contrôle par exemple)

Création d'un composant "RemoteComponent" sans enfant

Le principe est le même que précédemment sauf que ce composant se retrouverait sur une page vide et déclencherait la navigation vers la page suivante lorsque les données sont chargées.

{
  "componentType": "RemoteComponent",
  "endpoint": {
    "url": "https://insee.fr/autocomplete/address",
    "data": "content.data"
  },
  "responses": [
    {"name": "ID"},
    {"name": "CODE"}
  ],
}

Dès que ce composant est monté il contacte le serveur (en envoyant les données correspondant à "responses") pour obtenir les données à hydrater. Une fois la réponse obtenue les données sont passée à Lunatic et on navigue à la page suivante. Le composant affiche un spinner pendant qu'il contacte le serveur.

🟢 Approche réutilisable
🟢 On peut remplir n'importe quel champs
🔴 On introduit un nouveau composant et une page vide

Création d'une propriété "fillers"

Vu que la logique est annexe au formulaire on pourrait déplacer la logique dans une propriété dédiée (au même titre que "cleaning" ou "resizing".

{
  "fillers": [
    {
      "page": "2",
      "endpoint": {
        "url": "https://insee.fr/autocomplete/address",
        "data": "content.data"
      },
      "responses": [
        {"name": "ID"},
        {"name": "CODE"}
      ]
    }
  ]
}

On indiquerait ici à quel page le système de remplissage doit se déclencher, dès que l'utilisateur quitte cette page le serveur est contacté pour charger les données. Pendant ce chargement des données aucun composant n'est affiché côté Lunatic et on affiche un spinner.

🟢 Approche réutilisable
🟢 On peut remplir n'importe quel champs
🔴 Logique à rajouter lors de changements de page

renaud23 commented 4 months ago

Merci Jonathan pour cette synthèse. Le cas d'usage décrit correspond en effet au notre : suggérer depuis un service distant une adresse selon des valeurs fournies par le répondant. Pour le choix de la solution, pourvu que ça marche... Celle que je t'avais proposé collait bien à notre de cas d'usage, mais les autres peuvent peut-être couvrir des possibilités d'usages plus larges, pour d'autres enquêtes. On peut peut-être en implémenter plusieurs ;) Sinon, au RP nous sommes encore sur la version 2 pendant un an. Il faudra donc qu'on prenne soin d'implémenter la solution retenue dans toutes les versions.

ddecrulle commented 4 months ago

Nous devons déterminer le moment optimal pour envoyer la requête vers l'API. Qu'est-ce qui est souhaité ? Au changement de page, à la fin du remplissage de tous les champs ?

Personnellement, je suis réticent à l'idée d'introduire un nouveau composant tel que RemoteComponent. En effet, les composants décrits dans le modèle correspondent à des éléments d'interface utilisateur affichés à l'écran.

Je préconise plutôt la dernière solution, qui consiste à ajouter une propriété fillers.

Pour entamer le développement, il est essentiel de définir avec précision les besoins et de structurer le modèle pour cette nouvelle propriété.

laurentC35 commented 4 months ago

Merci Jonathan pour cette synthèse. Le cas d'usage décrit correspond en effet au notre : suggérer depuis un service distant une adresse selon des valeurs fournies par le répondant. Pour le choix de la solution, pourvu que ça marche... Celle que je t'avais proposé collait bien à notre de cas d'usage, mais les autres peuvent peut-être couvrir des possibilités d'usages plus larges, pour d'autres enquêtes. On peut peut-être en implémenter plusieurs ;) Sinon, au RP nous sommes encore sur la version 2 pendant un an. Il faudra donc qu'on prenne soin d'implémenter la solution retenue dans toutes les versions.

Hello, aujourd'hui vous n'aviez pas déjà ce fonctionnel qui existe dans le couple StromaeV3 (RP) + Lunatic 2.6 ? Merci de ta réponse

InseeFr / Lunatic