Dropdown performance

[mull]

We're in a situation where we have a form that generates another set of inputs. Each set of inputs renders a with around 1400 items.

We're seeing quite terrible performance here, even with NODE_ENV=production and propType validation turned off. Using profiling in Chrome we're seeing that most of the time is spent either mounting or updating components.

The component will render all of its options immediately. Would it be a good idea to make it only render these options once the Dropdown is opened (perhaps by a prop toggle?)

Our generation of the list of options sent down to the dropdown are memoized (verified) and not part of the problem.

By this issue I would like to open up the discussion on how we 1) can make sure the component is performant as consumers and/or 2) provide performance improvements to the Dropdown codebase.

Any help/pointers appreciated. If us developers here at this company feel we can reasonably tackle this task we will happily take it on!

Thanks, and happy weekend!

[levithomason]

I don't think it is good practice to render 1400 items to the DOM in a component like this. These items should be kept and filtered in memory only and a truncated list of items should be rendered to the DOM. Example, you can performantly search 1400 objects in memory only but only render the top 10, 20, or 50 to the DOM for the user to scroll through. This is not only performant, but it is better for the user, since, almost no one would scroll 1400 items to find what they need :)

That said, performance improvements are always welcome. We have several ongoing efforts for performance at the moment, though, Dropdown items is not one of them.

It would be great if we could get a perf branch going where we can profile and test the Dropdown (and other components) properly. This way we can correctly diagnose and improve areas that are eating up resources.

[levithomason]

For a little more direction, we could install perf tools as dev deps, which makes them available locally in the doc site. Then, when in __DEV__ we can add a perf route to the docs. This way, developers have a perf route they can go to in order to handle all things perf.

Depending on how this page is done, it may even make it to the live docs. Might be kind of cool to have perf info on the live doc site as well.

[mull]

I don't think it is good practice to render 1400 items to the DOM in a component like this. These items should be kept and filtered in memory only and a truncated list of items should be rendered to the DOM.

I guess you're right. Rather than relying on completely we should be doing our filtering and only providing the component with the options we indeed want to show since we're using search with it anyhow.

[levithomason]

Sounds good. I'll close this for housekeeping for now. PRs gladly welcomed.

[qoalu]

can we implement something like react-virtualized for dropdowns within the library?

[layershifter]

I will glad to see PR for this 👍

[pirey]

I guess you're right. Rather than relying on completely we should be doing our filtering and only providing the component with the options we indeed want to show since we're using search with it anyhow.

hi @mull , can you share what to do to achieve the functionality you mentioned above?