UI hangs on really large lists

[mcclurem]

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.

[tjschuck]

@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:

1. 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.
2. We've historically rejected that kind of "delayed searching until n characters" because of UX issues. See Add option for minimum term length to start search #2359 and its linked issues. However, there is an alternative solution: max_shown_results introduced in Added option max_shown_results #2362. It was specifically added "to increase performance of selects with very many options", so this is probably what you're after. More information about max_shown_results can be found in the docs.

[Reelix]

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?)

[steckdev]

@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.

[selvarajpalani]

+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.