Chosen: UI hangs on really large lists
Version 1.5.1;
Browsers tested: Chrome, Safari;
assumed to apply universally
When working with /truly/ large selects (20K elements), the responsiveness of filtering leaves a bit to be desired.
I think two key aspects could be dramatically improved:
1) when clicking to cause the select box to open, don't search every item with a blank regex, simply populate the complete list - this should reduce select-opening time dramatically and it's probably the most noticeable part of the user experience problem.
2) When typing, the search should have the option to be debounced (ideally with config defined duration?) so that the user can type several characters before it actually starts searching. Possibly this could even be done intelligently based on the number of pre-existing matches before searching (if winnowing an already small list, don't debounce as long)
I'm looking into implementation details myself but if one of the regulars around here sees how to easily add one or both of these and can bang it out (or point me towards where to do it) that would be great.
mcclurem
All 4 comments
@mcclurem Thanks for your report!
There have been a few previous issues about performance problems with many thousands of options — see #2158 as an example.
As for your two specific notes:
- Needlessly calling the blank regex on every element on-open does seem bad! Please feel free to investigate a solution and submit a PR to fix this if possible.
- We've historically rejected that kind of "delayed searching until _n_ characters" because of UX issues. See #2359 and its linked issues. _However_, there is an alternative solution:
max_shown_resultsintroduced in #2362. It was specifically added "to increase performance of selects with very many options", so this is probably what you're after. More information aboutmax_shown_resultscan be found in the docs.
tjschuck
on 28 Mar 2016
RE Option 2
Whilst max_shown_results speeds up searches dramatically (I have a list of 22k elements), we need some way to indicate that there are additional items that are simply being hidden.
I suggest something along the lines of a "Show more" / "Show next x" at the bottom of the list to display an additional x (Where x = max_shown_results). Whilst this will partially negate the speed up provided by the original limitation, it will indicate that the list contains additional items. An alternative would simply be something like "..." at the bottom in grey to indicate additional hidden options (Possibly text the user can change in the initialization?)
Reelix
on 23 May 2016
@mcclurem What did you do for you large lists in Chosen? Were you able to find any reasonable workaround? Did you change the way you loaded the values into chosen? Is there a better way to lazy load with still having search? We are looking at having 100,000 items in our results. We currently limit the view to only show 50. But the search client side would need them loaded for chosen to perform the search.
steckdev
on 4 Jan 2017
+1. Major cons of this plugin I think would be the performance and expecting something like lazy loading will solve the issue. This is the only huge gap I see in chosen.
selvarajpalani
on 28 Jun 2018
Related issues
jim-at-miramontes
·
4Comments
blankhang
·
7Comments
gandarez
·
5Comments
ali1360
·
5Comments
alexfrancavilla
·
9Comments
Most helpful comment
RE Option 2
Whilst
max_shown_resultsspeeds up searches dramatically (I have a list of 22k elements), we need some way to indicate that there are additional items that are simply being hidden.I suggest something along the lines of a "Show more" / "Show next x" at the bottom of the list to display an additional x (Where x = max_shown_results). Whilst this will partially negate the speed up provided by the original limitation, it will indicate that the list contains additional items. An alternative would simply be something like "..." at the bottom in grey to indicate additional hidden options (Possibly text the user can change in the initialization?)