Enterprise: Desplegable/Multiselección: Refactorizar para usar un objeto de fuente de datos en lugar de un elemento Seleccionar

NOTA: Este problema potencialmente soluciona algunos problemas de rendimiento identificados en el n.º 843 (y otros).

¿Tu solicitud de función está relacionada con un problema?
El Dropdown/Multiselect actual que enviamos con IDS se creó como una capa de interacción sobre el elemento HTML estándar <select> , manejando la selección de sus opciones en configuraciones únicas/múltiples.

Los casos de uso de este componente han aumentado con el tiempo para incluir el filtrado de las opciones disponibles, lo que ha llevado a los equipos a usar el menú desplegable/selección múltiple para conjuntos de datos extremadamente grandes (superando los 2000 elementos a la vez, en algunos casos). Si bien nuestro equipo mantiene que no recomendamos usar este componente para conjuntos de datos tan grandes, seguimos teniendo problemas que solicitan que abordemos el rendimiento en estos niveles. Algunos problemas anteriores que hemos solucionado incluyen:

• https://jira.infor.com/browse/SOHO-5693
• https://jira.infor.com/browse/SOHO-5192
• https://jira.infor.com/browse/SOHO-7816
• #843 siendo el último

Muchos de esos problemas dejan la advertencia de "todavía no es genial, pero es mejor". La razón de esto es que el diseño de Dropdown/Multiselect en su núcleo no se presta bien a conjuntos de datos tan grandes. Si queremos solucionar los problemas de rendimiento, debemos abordar los fundamentos de su diseño.

Describa la solución que le gustaría
Una posible ruta de solución para corregir el rendimiento de Dropdown/Multiselect:

• [ ] Un requisito estricto para usar <select> como fuente de datos principal. Algunas mejoras recientes del n.° 267 comenzaron a trazar cómo una llamada AJAX podría generar un objeto de datos para Dropdown que podemos almacenar en el cliente. Creo que deberíamos avanzar hacia el uso de un objeto con algunos estados simples (deshabilitado/seleccionado/etc.) como el controlador principal del comportamiento del componente, en lugar de obtener esta información de un elemento DOM. La representación de la etiqueta <select> y sus <option> seguirán siendo necesarias para cosas como el envío de formularios, pero debemos definir el objeto de datos como la "fuente de la verdad" y dibujar la etiqueta de selección basado en el objeto (no al revés).
• [ ] También explore simplemente no representar/depender de una etiqueta <select> en ningún sentido. Puede ser un caso de uso razonable para un desarrollador que utiliza Dropdown/Multiselect con tantos elementos para simplemente interceptar una solicitud de envío de formulario y enviar el estado del objeto de fuente de datos en lugar de confiar en el proceso de envío de formulario normal. Actualmente, este tipo de uso no es posible.
• [ ] Una vez que ya no dependemos del elemento DOM, podemos comenzar a explorar mostrando solo un subconjunto de elementos de lista en el DOM en un momento dado. Dado que el objeto de la fuente de datos retiene el estado, el DOM no necesariamente importa, y debería ser mucho más trivial cargar/descargar pequeñas cantidades de elementos de la lista a medida que un usuario se desplaza por una lista (nos permitiría explorar #460 en Desplegable).
• [ ] Cree mejores recomendaciones para el manejo del lado del servidor de grandes conjuntos de datos. Incluso retener el estado en un objeto del lado del cliente con tantos registros puede volverse muy lento. Es posible que queramos tener una recomendación y/o algunas demostraciones de cómo podríamos querer que las implementaciones de IDS manejen los registros desplegables/de selección múltiple en el servidor.

Describa las alternativas que ha considerado
Algunas otras ideas que hemos planteado en el pasado:

• Un componente más simple que superpone etiquetas <select> y les da estilo, en lugar de generar pseudomarcas para las interacciones. Esto podría manejar mejor la lista más grande ya que no la duplicaría. Todavía tendríamos que manejar 2000 elementos a la vez en este caso.