sigrennesmetropole / geor_tabou2_front

Code du front de l'application tabou2 pour georchestra
Other
1 stars 2 forks source link

Autocomplétion - utiliser l'API #123

Closed Gaetanbrl closed 3 years ago

Gaetanbrl commented 3 years ago

Description

Suite à la livraison 1.1.4 il est vérifié que le total de résultats peut être supérieur au nombre de résultats retournés par l'API (max 100).

Même si la limite est modifié (ex: max 200) il n'est pas garantit que les valeurs retournées par l'API ne dépasse pas cette nouvelle limite.

En utilisant l'autocomplétion du composant par défaut (ce qui a été convenu initialement pour la v1), la liste n'est pas rechargée à la saisie et il n'est pas possible de retourner un nombre de résultat inférieur car la liste se charge une seule fois à l'initialisation. Lors d'une saisie, le composant recherche dans les valeurs chargées à l'initialisation et non via des appels API.

Pour être certain que l'utilisateur trouve ce qu'il recherche, l'API doit être utilisée pour l'autocomplétion sans utiliser l'autocomplétion de base du composant.

Les éléments concernés dans un premier temps sont :

dcottenc commented 3 years ago

A ajouter dans ce besoin, qu'un message devrait apparaitre en invitant l'utilisateur à affiner la recherche dès que le nombre de réponse est inférieur au nombre d'éléments indiqués dans le résultat.

Les deux API emprises OA et PA sont à faire modifier.

Gaetanbrl commented 3 years ago

@dcottenc demande validation pour ce comportement non décrit précisément :

1. Par défaut, si l'API retourne un nombre de résultats inférieur au nombre de résultats attendues ==> on informe l'utilisateur qu'une saisie est requise et on ne charge rien dans la liste (liste vide si on clique sur la flèche, le message pouvant être "veuillez saisir un nom" à l'ouverture de la liste vide ).

Test réalisé (reprise du component cadastrapp)

image

2. Si l'API retourne un nombre de résultats < ou = au nombre annoncé (champ totalElements) alors on affiche toute la liste comme c'est le cas actuellement

image

Gaetanbrl commented 3 years ago

A ajouter dans ce besoin, qu'un message devrait apparaitre en invitant l'utilisateur à affiner la recherche dès que le nombre de réponse est inférieur au nombre d'éléments indiqués dans le résultat.

Je propose d'ajouter pour chaque filtre un text comme pour les dates. A côté du texte, lorsqu'une autocomplétion par début de saisie est attendue, on affichera un icône avec un message qui s'affiche au survol de la souris.

image

Est-ce que cela convient @dcottenc ?

Gaetanbrl commented 3 years ago

je complète @dcottenc après réflexion :

Il serait préférable de savoir à l'avance lesquels dépassent... je ne vois pas comment faire pour savoir à l'avance lesquels nécessitent une autocomplétions et lesquels non à moins de faire des appels en série pour examiner les retours (peu performant et pas du tout optimal) afin de savoir quel composant choisir.

dcottenc commented 3 years ago

Est-ce que cela convient @dcottenc ?

A confirmer demain avec la MOA

Il serait préférable de savoir à l'avance lesquels dépassent...

Je ne suis pas certain de bien saisir la question. Mais s'il s'agit de faire une liste fixe des champs avec liste déroulante avec ce traitement, je peux voir ca avec la MOA

Gaetanbrl commented 3 years ago

Je ne suis pas certain de bien saisir la question. Mais s'il s'agit de faire une liste fixe des champs avec liste déroulante avec ce traitement, je peux voir ca avec la MOA

Au chargement des combobox, soit on affiche une liste entière, soit on affiche rien et l'utilisateur doit saisir des caractère pour démarrer une recherche sur autocomplétions.

Actuellement, le seul moyen de faire la différence c'est d'appeler l'API et de comparer le nombre de résultats attendus / le nombre de résultats retournés dans le corps de la réponse.

On doit donc faire 1 appel test pour tous les champs. Je préfèrerai que l'on fixe d'avance les champs avec saisie obligatoire (Par exemple dans cadastrapp, les valeurs étant larges on a par défaut toutes les listes en saisie obligatoire, il n'y a pas d'appel préliminaire).

dcottenc commented 3 years ago

Je préfèrerai que l'on fixe d'avance les champs avec saisie obligatoire

Je pense également que cette liste de champs doit être fixe. Contrairement à CadastrApp, nous avons besoin de champs avec des listes déroulantes pre chargés car peu de valeurs (ex : Etape)

Gaetanbrl commented 3 years ago

Je pense également que cette liste de champs doit être fixe

Parfait ! En attente d'une liste avec la MOA donc.

Gaetanbrl commented 3 years ago

@dcottenc les PLUI sont du moins déjà testables sur le contexte de VA

dcottenc commented 3 years ago

@Gaetanbrl la liste PLUi est toujours vide même quand je commence à saisir (sous Firefox) Dans l'exemple suivant, il y a normalement 19 zonages seulement

image

Gaetanbrl commented 3 years ago

Le nombre de caractère est à minima de 3 en général avant de lancer la recherche, quels sont les attentes pour ce comportement ? A partir de un caractère ?

dcottenc commented 3 years ago

Le nombre de caractère est à minima de 3 en général

Oui effectivement mais dans le cas du PLUi, dès le premier caractère c'est discriminant et surtout il y a des zones nommées avec 1 ou 2 caractères qu'il faut pouvoir sélectionner

Gaetanbrl commented 3 years ago

@dcottenc à prévoir avec la liste des champs :

  1. autocomplétions ou liste fixe
  2. nombre de caractère mini avant l'exécution de la recherche (inutile de bombarder l'API à partir de 1 caractère saisie pour tous les champs je suppose)
Gaetanbrl commented 3 years ago

En cours :

Gaetanbrl commented 3 years ago

@dcottenc visible sur context VA

Gaetanbrl commented 3 years ago

Rajouté par @dcottenc le 17/08/21.

Gaetanbrl commented 3 years ago

@dcottenc j'ai placé dans l'issue 80 cette fonction d'autocomplétions. SI le reste est valide on peut fermer celle-ci.

dcottenc commented 3 years ago

Lors des tests, j'ai des comportements bizarres et différents selon les cas.

Gaetanbrl commented 3 years ago

Correctifs Testable sur le contexte VA @dcottenc

dcottenc commented 3 years ago

Encore deux choses (valable pour tous les champs) :

Gaetanbrl commented 3 years ago

En attendu, on aurait plutôt une liste vide.

C'est le comportement des combo dans cadastrapp. Jusque là ce ne me choque pas. Ca permet même de garder une liste chargée (un peu comme un historique de la dernière valeur recherchée).

En attendu, ne devrait-elle pas être supprimée ? Il y a un risque d'erreur à l'enregistrement.

Idem, comportement par défaut. Je peux rajouter une évolution sur cette combo pour forcer la sélection. Car dans certains cas, on peut vouloir saisir / coller la valeur comme pour un champ date.

dcottenc commented 3 years ago

Encore deux choses (valable pour tous les champs) : Si on utilise des caractères qui retournent des valeurs dans la liste, puis on clique sur la croix, alors si on clique sur la liste déroulante on retrouve les valeurs précédentes. En attendu, on aurait plutôt une liste vide. Si on utilise des caractères qui ne retournent une liste vide, puis on clique ailleurs (perte focus), alors la valeur erronée reste affichée. En attendu, ne devrait-elle pas être supprimée ? Il y a un risque d'erreur à l'enregistrement.

Après vérification, le comportement est identique dans Cadastrapp.

Corrections testées et validées.