By default, the select component will render all of their options values, which can be a (potentially serious) performance issue as DOM elements are created for every one.
We have an enabledWindowed prop that is usable under certain circumstances - not async, not creatable - and will use a virtual rendering window to avoid this issue. But that prop is false by default, and again cannot be used in all cases.
We should investigate if the option should always be on by default, when possible.
If there is some downside to this, could it be auto-activated, when possible, if the number of options exceeds some threshold?
Has the story around this option changed in any significant way with the newer release of both underlying components (see #3426)? We might well want to revisit that upgrade before changing anything substantial here.
For async queries, right now the responsibility is on the developer to return a "reasonable" number of results, without any guidance on what that might be. Could we experiment to come up with a recommendation, and then potentially even enforce that as a limit, truncating returned results? There is little utility in showing the user a very long list of matches - if longer than a few dozen, they should almost certainly be encouraged to type more and get more focused results.
The risk with the status quo is that a select might appear to behave very well in development or with some surrounding query that limits its options, but then if a long list of is unexpectedly presented, the rendering delay can be bad enough to freeze up the browser.
By default, the
selectcomponent will render all of their options values, which can be a (potentially serious) performance issue as DOM elements are created for every one.We have an
enabledWindowedprop that is usable under certain circumstances - not async, not creatable - and will use a virtual rendering window to avoid this issue. But that prop is false by default, and again cannot be used in all cases.The risk with the status quo is that a select might appear to behave very well in development or with some surrounding query that limits its options, but then if a long list of is unexpectedly presented, the rendering delay can be bad enough to freeze up the browser.