carbon
carbon copied to clipboard
Virtual scrolling for FilterableSelect component
Desired behaviour
Please can you provide virtual scrolling for the FilterableSelect to improve performance for 10k+ selectable options.
Current behaviour
Performance degrades when there are 10k+ selectable options.
Suggested Solution
Use virtual scrolling in order to reduce the number of concurrently rendered selectable options.
CodeSandbox or Storybook URL
No response
Anything else we should know?
No response
Confidentiality
- [X] I confirm there is no confidential or commercially sensitive information included.
@harpalsingh @ljemmo is there a reasonable use case for having a Select with 10k options, or is there some other UI pattern which might be more appropriate?
If it has to be a Select we can look at adding this feature but it will be complex to do and further complicate our Select component, which is already quite complex.
The only usecase i can think of would be for a list of products or maybe contacts that are to be selected in a form. Perhaps for larger businesses it may be realistic. I wonder if Mervyn could give more details on where this request came from?
hi, the use case is to be able to select from up to about 20k customers.
Let me try and add some more context.
Some Select components may contain thousands of values. In certain situations we might be required to use multiple Select components on the same webpage. Furthermore, in addition to the Select components there might be additional data-heavy components, such as tables.
Examples for lists to select from containing thousands of values might be the dimensions taken from the Sage Intacct application: https://www.sageintacct.com/products/accounting-software/financial-reporting-dashboards/multidimensional-system
In these webpages the application starts lagging, causing even hovering to become unpleasant. Moreover, the experience deteriorates when using less powerful workstations.
I found a nice example, which I haven't looked into deeply enough yet, but it demonstrates the virtualized-select concept well: https://github.com/guiyep/react-select-virtualized
thanks mervyn and ophir for the clarifications.
Just to be clear myself - we are aware of what you mean by "virtual scrolling". It is the right solution to use if we really do need Selects with thousands of options. I was just trying to clarify with the design team whether such "heavy" selects are 100% needed or if there is some other option from the design side.
While in theory this could be implemented in Carbon it's going to be quite a lot of work and is likely to lead to future maintenance headaches - so we just want to make sure it's absolutely needed before we commit to any work on this.
@ljemmo what are your thoughts? Are there any alternatives here?
Thanks @robinzigmond.
We will happily join and assist to the efforts around the request.
@robinzigmond i can't think of any alternatives i'm afraid and think this might be something we have to support especially for large biz where 1000s of products or customers could live within one dropdown list.
Thanks @robinzigmond and @ljemmo.
how do we proceed from here?
@ophir-gross-sage from a design perspective, i'm happy for a FEET ticket to be generated. This will now need triaging from Nick and Robin's perspective.
Another performance related issue that could be considered is debouncing the filtering when the text is changed.
OK, thanks all - I'll create a ticket on our backlog for this. We can discuss it within the team at our next refinement session which will be on Wednesday - although this one might need further discussion with @nicktitchmarsh who is on holiday till the end of the week, I'll try to pick this up with him next week.
FE-5394