Chosen: La interfaz de usuario se cuelga en listas realmente grandes

Creado en 28 mar. 2016 · 4Comentarios · Fuente: harvesthq/chosen

Versión 1.5.1;
Navegadores probados: Chrome, Safari;
se supone que se aplica universalmente

Cuando se trabaja con /verdaderamente/ selecciones grandes (elementos 20K), la capacidad de respuesta del filtrado deja un poco que desear.
Creo que dos aspectos clave podrían mejorarse drásticamente:
1) al hacer clic para que se abra el cuadro de selección, no busque cada elemento con una expresión regular en blanco, simplemente complete la lista completa; esto debería reducir drásticamente el tiempo de apertura de selección y es probablemente la parte más notable del problema de la experiencia del usuario.
2) Al escribir, la búsqueda debe tener la opción de ser rebotada (¿idealmente con una duración definida por la configuración?) para que el usuario pueda escribir varios caracteres antes de comenzar a buscar. Posiblemente, esto incluso podría hacerse de manera inteligente en función de la cantidad de coincidencias preexistentes antes de buscar (si está filtrando una lista que ya es pequeña, no rebote tanto tiempo)

Estoy investigando los detalles de implementación yo mismo, pero si uno de los habituales por aquí ve cómo agregar fácilmente uno o ambos y puede resolverlo (o indicarme dónde hacerlo), sería genial.

Performance

Fuente

mcclurem

👍1

Comentario más útil

RE Opción 2

Si bien max_shown_results acelera drásticamente las búsquedas (tengo una lista de 22k elementos), necesitamos alguna forma de indicar que hay elementos adicionales que simplemente se ocultan.

Sugiero algo como "Mostrar más" / "Mostrar siguiente x" en la parte inferior de la lista para mostrar una x adicional (Donde x = max_shown_results). Si bien esto anulará parcialmente la aceleración proporcionada por la limitación original, indicará que la lista contiene elementos adicionales. Una alternativa sería simplemente algo como "..." en la parte inferior en gris para indicar opciones ocultas adicionales (¿posiblemente el texto que el usuario puede cambiar en la inicialización?)

Reelix en 23 may. 2016

👍6

Todos 4 comentarios

@mcclurem ¡ Gracias por tu informe!

Ha habido algunos problemas anteriores sobre problemas de rendimiento con muchos miles de opciones; consulte el n.º 2158 como ejemplo.

En cuanto a sus dos notas específicas:

¡Llamar innecesariamente a la expresión regular en blanco en cada elemento abierto parece malo! Siéntase libre de investigar una solución y enviar un PR para arreglar esto si es posible.
Históricamente, hemos rechazado ese tipo de "búsqueda retrasada hasta _n_ caracteres" debido a problemas de UX. Ver #2359 y sus problemas vinculados. _Sin embargo_, existe una solución alternativa: max_shown_results introducido en #2362. Se agregó específicamente "para aumentar el rendimiento de las selecciones con muchas opciones", por lo que probablemente esto sea lo que está buscando. Puede encontrar más información sobre max_shown_results en los documentos .

tjschuck en 28 mar. 2016

RE Opción 2

Si bien max_shown_results acelera drásticamente las búsquedas (tengo una lista de 22k elementos), necesitamos alguna forma de indicar que hay elementos adicionales que simplemente se ocultan.

Reelix en 23 may. 2016

👍6

@mcclurem ¿Qué hiciste por tus grandes listas en Chosen? ¿Pudiste encontrar alguna solución razonable? ¿Cambió la forma en que cargó los valores en los elegidos? ¿Hay una mejor manera de cargar de forma diferida sin tener aún la búsqueda? Estamos buscando tener 100,000 artículos en nuestros resultados. Actualmente limitamos la vista para mostrar solo 50. Pero el lado del cliente de búsqueda los necesitaría cargados para realizar la búsqueda.

steckdev en 4 ene. 2017

👍1

+1. Las principales desventajas de este complemento creo que serían el rendimiento y esperar que algo como la carga diferida resuelva el problema. Esta es la única gran brecha que veo en los elegidos.