Redash: Multiselect dropdown slowness

Created on 21 May 2020  路  8Comments  路  Source: getredash/redash

Issue Summary

Multi-select parameter dropdowns are super slow when the item list consist 900 items.

Steps to Reproduce

  1. Create a multi-select parameter with either hard coded values or the query result
  2. Try to select a few items

Technical details:

  • Redash Version: 9.0.0-alpha (dev)
  • Browser/OS: latest Chrome/Firefox
  • How did you install Redash: Docker

This is what's missing to solve this issue

Bug Frontend hacktoberfest

Most helpful comment

Ant design was upgraded to v4 馃帀

Now to solve this all we need is to remove dropdownMatchSelectWidth={false} from the Select components, downside is that this will make Options width always match the Select width, which sometimes is very small. To make it a little bit better we may want to add a min-width for the options.

Changing the prop to a number value should also work (relevant docs): dropdownMatchSelectWidth={150} (need to see the value for each context).

All 8 comments

This is more feature request than bug. Can you open a thread on the forum instead? Any <select> component is going to struggle with that many options. It probably needs an AJAX auto-complete system to really fly.

900 items is something that I would expect still to work. @iherasymenko can you elaborate on whether the UI itself becomes slugish or just filtering the list?

Here is the video. The issue is that after selecting an item on a huge list it takes ~ 2 seconds to see it selected. For these two seconds the UI is frozen.

redash_dropdown

I created a query in the preview environment to track this issue. I believe what may be causing it is the code to check whether all selected options are on the list. I'll give a check on it and see if I have a quick solution to improve that :+1:

Just checked, turns out I was wrong, that method runs faster than I thought. I had Lodash's intersection as an issue in mind, that should cause issues for really large sets, but 1000 - 10000 should still be fine. (My plan was to use an internal Set to make the assertion faster 馃槄 ).

The problem is with Antd and it was fixed in v4, should work fine when we make the effort to upgrade from v3 (see here).

@gabrieldutra Thank you very much for looking into this. Is updating Antd something envisioned? I'd be happy to work on this update if this kind of change is aligned with the overall product vision/plan.

Is updating Antd something envisioned?

Yes, but it's unclear how much effort it will require so currently wasn't prioritized.

Ant design was upgraded to v4 馃帀

Now to solve this all we need is to remove dropdownMatchSelectWidth={false} from the Select components, downside is that this will make Options width always match the Select width, which sometimes is very small. To make it a little bit better we may want to add a min-width for the options.

Changing the prop to a number value should also work (relevant docs): dropdownMatchSelectWidth={150} (need to see the value for each context).

Was this page helpful?
0 / 5 - 0 ratings