Le popup de recherche / liste d'options énumérées (très) longue sort de l'écran et est tronqué

Bonjour,
Nostra culpa, nous travaillons avec des métiers qui produisent des listes de références tel Prévert et son “Inventaire” (ce que nous ne pouvons pas changer à court terme).

Nous avons donc des énumérations d’options qui dépassent de beaucoup la taille de l’écran / du viewport géré par la UI (les boutons “rechercher” & co. ne sont pas visibles non plus que la fin de la liste).

Afin de contourner ce problème, j’ai ajouté dans les styles additionnels de mon thème le bloc suivant:

.dropdown-menu { max-height: calc(60vh); overflow-y: auto; }

ça répond a priori au besoin mais est-ce la bonne manière de faire / cela présente-t-il un risque par ailleurs / est-ce à reconduire en v5 ?

PS: nous sommes en Version=4.0.P25 BuiltOn=2021-04-16 22:48 (revision 4ab14992fb5c4cd36c952b89d0eae09a99a41828)

Indépendamment de la réponse sur les styles, les listes de valeurs ne sont pas faites pour des listes “à rallonge”. Quand on dépasse 50-100 items il vaut mieux les transformer sur un objet métier de référence avec des logiques de lookup/completion.

C’est d’autant plus nécessaire quand ces listes évoluent dans le temps.

Perso je ne configure sous forme de liste de valeur que les données “immuables” (ex: la liste des jours de la semaine, des civilités, etc.) le reste j’en fais des objets de référence (avec une FK en rendering lien popup+select pour avoir un look and feel proche d’une dropdown)

Oui, absolument… il s’agit en effet d’une liste qui n’est pas censé évoluer beaucoup (elle n’avait pas bougé depuis 2017) et qui est sourcée en amont (pas modifiable dans notre système ou seulement par l’ADMIN).

Donc oui, je souscris complètement à ton avis mais il s’agit de contourner à court terme le problème en repoussant le tas de sable plus loin (transformer la liste en objet métier avec un certain nombre de cas à gérer car il s’agit d’options essentiellement utilisées pour filtrer ou croiser les données).

Oui l’approche CSS avec Bootstrap V3 est la bonne même si en terme UX c’est plus du Beckett que du Prevert.

max-height = taille humainement lisible = les experts en UX préconisent entre 7 et 15 items dans un dropdown 60vh ça doit être à peu près ça… sinon 30rem

En V5 / Bootstrap V4, c’est popper qui le positionne pour être visible, mais effectivement si ça dépasse la hauteur de l’écran ça ne doit pas marcher sans directive de scroll explicite.
La logique serait plutôt de mettre un scroll sur les items (hauteur max fixe) et que les 2 boutons “Rechercher / Annuler” soient toujours visibles en bas du dropdown (hors scroll).

Si tu fais référence à “l’Innommable”, alors oui, on y est…
Merci pour le retour (je note de retirer mon truc crado lors de l’upgrade V5; le refactoring en objet métier pour revenir dans la bonne pratique, ce ne sera peut-être pas avant la V6 lorsque notre source aura publié une asyncAPI sur ses propres références).

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.