Enterprise: El control desplegable de selección múltiple tiene un rendimiento deficiente en IE11 cuando la lista desplegable contiene +500 opciones

Los resultados de nuestra prueba para esto me parecen mucho mejores que esos números.
http://master-enterprise.demo.design.infor.com/components/dropdown/test-2000-items.html

Quizás haya un problema con la selección múltiple específicamente. Tienen el mismo código pero algunas rutas diferentes.

Al final del código de prueba, ¿tenías uno? ¿O muchos menús desplegables?

@tmcconechy , para mis pruebas tengo 5 controles de selección múltiple en la página. Cuando cambio esos controles a un menú desplegable (sin selección múltiple), noto una mejora significativa en el rendimiento. Este problema parece específico de los controles de selección múltiple.

Hablando de este tema, ¿tiene un poco de curiosidad sobre el caso de uso real? ¿Qué tipo de elecciones de selección múltiple está haciendo el usuario?

@picitelli es la mejor persona para hablar.
Según tengo entendido, la lista debe construirse cada vez que se activa el menú desplegable y puede haber hasta alrededor de 2000 elementos según la función del usuario. Necesitan volver a cargar el menú desplegable en algunos puntos, pero no pueden comunicarse con el complemento de Mongoose.
No estoy seguro de qué tipo de elecciones de selección múltiple se están realizando.
He leído mucho sobre IE11 que tiene un rendimiento deficiente al agregar elementos al DOM en general e incluiré algunos enlaces a continuación.
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/4561410/
https://stackoverflow.com/questions/43003579/internet-explorer-11-very-slow-appending-elements-to-dom
https://stackoverflow.com/questions/24913564/appending-large-groups-of-elements-in-ie11-enormously-slow

Definitivamente, IE es lento en el DOM, pero me preguntaba el caso de uso real en el que al usuario se le muestran 500 cosas y tiene que elegir cuáles. Parece que tal vez un máximo de 50 opciones sería más apropiado para una interfaz de usuario de decisión / selección.

Probablemente podamos hacerlo más rápido, pero nos preguntamos si el caso de uso sería mejor servido por un componente diferente.

Seguramente sería mejor servido por un componente diferente, pero la pregunta del cliente es usar el menú desplegable. Si queremos volver atrás y decir, este no es el componente correcto y va a tener problemas en IE11 ... ¿tal vez actualizar a Edge? Supongo que podríamos ofrecer la sugerencia.

@tmcconechy , para nuestra aplicación, tenemos 4 controles desplegables de selección múltiple a los que un usuario puede acceder para filtrar los resultados en una página de lista de pedidos. La cantidad de opciones que aparecen dentro de estos menús desplegables se basan en la selección de un usuario y también en los permisos (rol) que se le otorgan a un usuario. Un usuario habitual estará limitado a ver solo una pequeña gama de opciones. Una vez que hacen las selecciones, tenemos una llamada a la API que llena más opciones en un control desplegable secundario que se usa para un filtrado adicional. (Estos menús desplegables se comunican entre sí).

Un usuario con permisos de administrador completos verá todas las opciones dentro del control desplegable. Por el momento, la cantidad total de opciones es 1969. Ese número puede crecer en función de lo que el cliente quiera usar.

Es posible que un usuario solo vea de 2 a 50 opciones dentro del control, pero si se le otorgan permisos adicionales, la cantidad de opciones que tiene puede expandirse hasta 1969. No queremos ofrecer otro control (por ejemplo, búsqueda de producto) que agregue un paso adicional para que interactúen y realicen su proceso de filtrado cuando el control de selección múltiple es la mejor opción, especialmente cuando la mayoría de los usuarios verán un número menor de opciones.

Es frustrante lidiar con IE11, y sé que el rendimiento no es óptimo cuando hay tantas opciones dentro del control. Este mismo control, usado sin la configuración "múltiple", y como solo un menú desplegable de selección única, no tiene las mismas preocupaciones de rendimiento en IE11 cuando hay ~ 2000 opciones. Solo como una selección múltiple existe este gran problema de rendimiento.

También desearía que fuera tan simple como decirles que actualicen su navegador, pero esta aplicación es para los clientes, que son predominantemente en IE11.

@tmcconechy @EdwardCoyle
He estado trabajando con diferentes soluciones para optimizar este código para IE y no he encontrado ninguna solución que, una vez implementada, aumente el rendimiento en IE11. Mi recomendación en este punto es retroceder y sugerir un componente diferente si desean un mejor rendimiento. A partir de este momento, el menú desplegable y la selección múltiple funcionan muy bien con hasta 500 elementos. 2000 como se solicita en este número me parecería excesivo para tal componente.
Feliz de recibir cualquier consejo o discutir aparte de este hilo de comentarios.

@picitelli, si la admitamos IE11 en esas condiciones, la solución no es sencilla. Nuestro componente Dropdown necesitaría una revisión bastante seria, ya que nunca fue diseñado con ese tipo de carga en mente.

@davidcarlsonberg @clepore @nickwynja @tmcconechy deberíamos charlar sobre este. Tengo algunas ideas sobre cómo abordar la actuación, pero esas ideas aterrizan en el territorio de la "refactorización".

Pensé que había una gran diferencia entre el menú desplegable con 2000 y la selección múltiple con 2000. ¿Exploraste la diferencia de velocidad allí para obtener una ganancia más inmediata?

Estaba buscando más en la causa raíz de la disminución del rendimiento. Puedo investigar la selección múltiple del menú desplegable frente al menú desplegable simple si queremos cambiar el alcance de este ticket para ver qué se puede ganar allí para una victoria rápida.

Sí, definitivamente vale la pena echarle un vistazo. Basé esta suposición en este comentario https://github.com/infor-design/enterprise/issues/843#issuecomment -424495956

Cualquier cosa puede ayudar, incluso si es un "poco" más rápido

Continuaré determinando y mejorando la diferencia entre el menú desplegable y la selección múltiple.

Creo que @EdwardCoyle tiene razón en que necesitaríamos revisar esto desde cero utilizando técnicas más modernas para la eficiencia. No estoy seguro de si vale la pena dedicar más de un día a esto @davidcarlsonberg .

@picitelli Seguiremos buscando opciones para abordar este caso de rendimiento

Creo que la mejor opción para este caso es usar un indicador de ocupado :

Un indicador de ocupado notifica al usuario que el sistema está procesando una solicitud y que debe esperar a que se procese esa solicitud antes de continuar con la tarea actual.

Aquí hay un ejemplo de cómo usarlo en un campo:

• https://design.infor.com/code/ids-enterprise/4.10.0/demo/busyindicator/example-inputs?font=source-sans
• https://github.com/infor-design/enterprise/blob/4.10.0/app/views/components/busyindicator/example-inputs.html

La mejor experiencia sería esperar un segundo más o menos y mostrar el indicador de ocupado solo si la lista aún no ha aparecido.

Tras el examen en Chrome reciente en macOS, la diferencia en el menú desplegable frente a la selección múltiple response() tiempo de ejecución. Tenga en cuenta las unidades.
menú desplegable: 512,14 ms
selección múltiple: 1,02 s

@tmcconechy @davidcarlsonberg @EdwardCoyle @clepore Agradezco a todos los que investigan este problema. Especialmente @davidcarlsonberg , gracias por dedicar tu tiempo a esto. Hemos estado intentando durante casi 2 semanas optimizar para IE11 y no encontramos nada más que callejones sin salida. Estoy de acuerdo con la evaluación de que este control no estaba destinado a manejar tantas opciones y que otro control sería más adecuado.

@nickwynja , tomará su recomendación de indicador ocupado con el diseño y verá lo que dicen.

¡Gracias de nuevo a todos!

Cerrando este problema ya que no hay pruebas de control de calidad involucradas. Consulte los comentarios para obtener más información.