Enterprise: Dropdown/Multiselect : Refactoriser pour utiliser un objet de source de données par opposition à un élément Select

REMARQUE : ce problème résout potentiellement certains problèmes de performances identifiés dans #843 (et autres).

Votre demande de fonctionnalité est-elle liée à un problème ?
Le Dropdown/Multiselect actuel que nous livrons avec IDS a été créé comme une couche d'interaction au-dessus de l'élément HTML standard <select> , gérant la sélection de ses options dans les paramètres simples/multiples.

Les cas d'utilisation de ce composant ont augmenté au fil du temps pour inclure le filtrage des options disponibles, ce qui a conduit les équipes à utiliser Dropdown/Multiselect pour des ensembles de données extrêmement volumineux (dépassant plus de 2 000 éléments à la fois, dans certains cas). Bien que notre équipe retienne que nous ne recommandons pas d'utiliser ce composant pour des ensembles de données aussi volumineux, nous continuons à rencontrer des problèmes nous demandant de traiter les performances à ces niveaux. Certains problèmes précédents que nous avons résolus incluent :

• https://jira.infor.com/browse/SOHO-5693
• https://jira.infor.com/browse/SOHO-5192
• https://jira.infor.com/browse/SOHO-7816
• #843 étant le dernier

Beaucoup de ces problèmes laissent la mise en garde de "ce n'est toujours pas génial mais c'est mieux". La raison en est que la conception du Dropdown/Multiselect à sa base ne se prête pas bien à des ensembles de données aussi volumineux. Si nous voulons résoudre les problèmes de performances, nous devons aborder les fondamentaux de sa conception.

Décrivez la solution que vous souhaitez
Une solution possible pour corriger les performances de Dropdown/Multiselect :

• [ ] Une exigence stricte d'utiliser <select> comme source de données principale. Certaines améliorations récentes de # 267 ont commencé à cartographier comment un appel AJAX pourrait générer un objet de données pour Dropdown que nous pouvons stocker sur le client. Je pense que nous devrions nous diriger vers l'utilisation d'un objet avec quelques états simples (désactivé/sélectionné/etc) comme principal moteur du comportement du composant, au lieu de récupérer ces informations à partir d'un élément DOM. Le rendu de la balise <select> et de ses <option> sera toujours nécessaire pour des choses comme la soumission de formulaire, mais nous devrions définir l'objet de données comme la "source de vérité", et dessiner la balise select basé sur l'objet (et non l'inverse).
• [ ] Explorez également simplement le fait de ne pas rendre/avoir une dépendance à une balise <select> dans aucun sens. Il peut s'agir d'un cas d'utilisation raisonnable pour un développeur utilisant Dropdown/Multiselect avec autant d'éléments pour simplement intercepter une demande de soumission de formulaire et envoyer l'état de l'objet de source de données au lieu de s'appuyer sur le processus de soumission de formulaire normal. Actuellement, ce type d'utilisation n'est pas possible.
• [ ] Une fois que nous ne dépendons plus de l'élément DOM, nous pouvons commencer à explorer uniquement l'affichage d'un sous-ensemble d'éléments de liste dans le DOM à un moment donné. Étant donné que l'état est conservé par l'objet source de données, le DOM n'a pas nécessairement d'importance, et il devrait être beaucoup plus simple de charger/décharger de petites quantités d'éléments de liste lorsqu'un utilisateur fait défiler une liste (cela nous permettrait d'explorer #460 sur Menu déroulant).
• [ ] Créer de meilleures recommandations pour la gestion côté serveur de grands ensembles de données. Même la conservation de l'état dans un objet côté client avec autant d'enregistrements peut éventuellement devenir très lente. Nous voudrions peut-être avoir une recommandation et/ou des démonstrations sur la façon dont nous pourrions vouloir que les implémentations d'IDS gèrent les enregistrements Dropdown/Multiselect sur le serveur.

Décrivez les alternatives que vous avez envisagées
Quelques autres idées que nous avons lancées dans le passé :

• Un composant plus simple qui superpose les balises <select> et les stylise, au lieu de générer un pseudo-balisage pour les interactions. Cela pourrait être en mesure de mieux gérer la plus grande liste car elle ne la dupliquerait pas. Nous aurions encore à gérer 2000 éléments à la fois dans ce cas.