Poor render performance on lists of >500 items

[carlpaten-ivadolabs]

I took the code from the static-data example and stuck it into an internal LOB application. The list of items contains ~700 entries. The first few keystrokes take about a second to register each, less and less as branches are culled out of the render tree.

One solution would be to add a props that sets a maximum limit of elements to render. Nobody wants to browse through a 700 element list, so all of that rendering effort is not going into good use anyway.

My work-around: having a local variable in render() that tracks the amount of items rendered. When it gets high enough, shouldItemRender returns false unconditionally.

let rendered = 0;
const maxRendered = 20;

let shouldItemRender = (branch, state) => {
    if (rendered < maxRendered) {
        let shouldRender = branch.Name.toUpperCase().indexOf(this.state.value.toUpperCase()) !== -1;
        if (shouldRender) {
            rendered += 1;
        }
        return shouldRender;
    } else {
        return false;
    }
}

EDIT: the above work-around actually isn't one, it breaks everything else. See #443.

[CMTegner]

The easiest solution is probably to cut/slice items before passing it to Autocomplete. You can control items entirely from the outside (i.e. sorting, filtering, etc) and specify that every item passed in should render (shouldItemRender={() => true}). Unless, of course, there's a technical reason why you couldn't create a shallow copy of the list.

[carlpaten-ivadolabs]

@CMTegner: but then, if filtering should be done on the items list before it is passed to Autocomplete, what is the point of exposing shouldItemRender?

[CMTegner]

if filtering should be done on the items list before it is passed to Autocomplete, what is the point of exposing shouldItemRender?

Yeah, you're sort of hitting an edge case usage-wise here. The current implementation was never meant to handle hundreds of items. Overriding shouldItemRender is simply an escape hatch which lets you disable some of Autocomplete's internal workings.

It's not unlikely that we'll move away from doing the filter and sort operations internally in the future, so this approach may end up being the way to use Autocomplete in the future.

On a related note: If you're doing filter/sort operations on large collections in the browser you should perhaps consider moving the heavy lifting to a ServiceWorker to prevent blocking the UI thread.

[marekolszewski]

@CMTegner Could we perhaps add a limitItemsLength prop to the component so that only the top x items will be shown after filtering and sorting? It would probably help a little with performance for long lists.

[CMTegner]

@marekolszewski this probably won't happen, as the goal is to move away from doing manipulations to items inside Autocomplete. As I said above, it's fairly easy to simply limit the number of items before passing them to Autocomplete.

[colinmegill]

FWIW, I landed on a different combination of libs because of this limitation and am switching off of react-autocomplete (20,000 items, so am imagining pretty rare :) if anyone else wanders across this issue, here's where I landed after a bit of searching:

https://codesandbox.io/s/LWMA9QZj

[zachgibson]

@colinmegill Do you have an example with 20K items?

[YoungElPaso]

@zachgibson this example also uses Downshift, and has about 1K entries :)

[FedeG]

@lilred work-arround/solution:

class LimitedAutocomplete extends Autocomplete {
  getFilteredItems(props) {
    let items = props.items

    if (props.shouldItemRender) {
      items = items.filter((item) => (
        props.shouldItemRender(item, props.value)
      ))
    }

    if (props.sortItems) {
      items.sort((a, b) => (
        props.sortItems(a, b, props.value)
      ))
    }

    return items.slice(0, props.limitItemsLength);
  }
}

Or

class LimitedAutocomplete extends Autocomplete {
  getFilteredItems(props) {
    const items = Autocomplete.prototype.getFilteredItems.call(this, props);
    return items.slice(0, props.limitItemsLength);
  }
}