Rendering long select lists in react can be very heavy and inefficient. The article shows how to use a common virtualization technique to reduce render time and significantly improve performance.

Efficient rendering of really large lists with react-select

<h2>Introduction</h2>
Using React as the UI framework of a web application always leaves developers with many choices through the development process. One of the most popular decisions to make is which Select component to use. React-select (<a href="http://react-select.com">react-select.com</a>) is the first choice when a select component (with many other features) is required - it has 20.5k stars on GitHub and 2 million weekly downloads on npm.&nbsp;
Like any common open-source component, react-select solves the common use cases very well. However, at the edges, react-select falls short sometimes and calls for customizations.
The problem we want to tackle with react-select is quite common: we want to allow selection from a large list of options. How large? We've seen the component start to break at around 1,000 options.&nbsp;
Keep reading and we'll show you how it breaks, and also demonstrate to you how we improved the performance by using another open-source library - <a href="https://github.com/bvaughn/react-window">react-window</a>. We'll also dive into the react-window implementation to understand how the improvement is achieved.
By the way - the entire code used in the post is public.

<h2>The problem - React select with large lists</h2>
To demonstrate the problem, we've created a new project with create-react-app. We added the react-select component by running `<code>yarn add react-select</code>`.
The most simple code for displaying a select component would be: 
<pre class="language-javascript"><code>import React, { useState } from "react";
import Select from "react-select";
import "./App.css";
 
const options = [...Array(100).keys()].map(idx =&gt; ({
 value: `value-${idx}`,
 label: `label-${idx}`,
}));
 
function App() {
 const [inputValue, setInputValue] = useState("");
 
 return (
 &lt;div className="App"&gt;
 &lt;header&gt;
 &lt;h1&gt;React-select With Large Lists&lt;/h1&gt;
 &lt;/header&gt;
 &lt;div style={{ width: "30%", margin: "auto" }}&gt;
 &lt;Select
 inputValue={inputValue}
 onInputChange={val =&gt; setInputValue(val)}
 options={options}
 /&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 );
}
 
export default App;</code></pre>
 
This would result in a high-performance select component, with 100 options. We'll use the same code to generate a large list of items to include in the select.
The following two gifs compare the performance of a select with 100 options to that of 10,000 options: 
<table>
<tbody>
<tr>
<td><img src="https://home.fasterthanlight.me/rails/active_storage/blobs/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBdHNCIiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--9b68801905f0b24ee608026b098b1ed251bb767f/1WNemZzm8ZLPIPcxs6Vse0ozqnXA1T0AGCLEZEFY.gif" alt="React select 100 options" width="595" height="455" /></td>
<td><img src="https://home.fasterthanlight.me/rails/active_storage/blobs/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBdHdCIiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--e361afc06a6675d4e27c79df72680391bebd6456/1Y89oZvmrGG0DmPHokp_6W54JjKhvx3wLwQskscw.gif" alt="React select 10,000 options" width="514" height="455" /></td>
</tr>
<tr>
<td>
React select 100 options
</td>
<td>
React select 10,000 options
</td>
</tr>
</tbody>
</table>
&nbsp;
The performance degradation is significant. With 10,000 options, the react-select component takes about 5 seconds to open its options menu. Why should it take so long? In both cases, only the first 8 or so options are visible. This is the first hint to how react-window approaches this problem - let's see more details.

<h2>React-window to the rescue</h2>
The key to improving the performance is limiting the rendering of the list. It's enough to only render 8 items while keeping the same usability as rendering all 10,000 items.&nbsp;
React-window is another prevalent open-source library, with 8.5k stars on Github and 300,000 npm downloads. React-window is used to render large lists in a virtual way: only the visible elements of the list are actually rendered.
How do we combine the two? Lucky for us, react-select exposes an API that allows us to replace any of its core building blocks. In this case, we would like to replace the MenuList component with our own, custom, MenuList. The new declaration of react-select would look like so:
<pre class="language-javascript"><code> ...
&lt;Select
 inputValue={inputValue}
 onInputChange={val =&gt; setInputValue(val)}
 options={options}
 components={{
 MenuList: CustomMenuList,
 }}
/&gt;
...</code></pre>
And now in our own CustomMenuList component, we utilize react-window to virtually render the list of options. To enable the virtualization, we must provide the virtual list with some basic data about the list: the list's height, and the height of each item in the list. That way the component knows exactly how many and which items to render.&nbsp;
The list's height is passed to the component as the props of the MenuList component, as provided by the react-select library. We determine the item heights ourselves, per our usability needs.
This is how the CustomMenuList ends up looking:
<pre class="language-javascript"><code>import { FixedSizeList as List } from "react-window";
 
const CustomMenuList = props =&gt; {
 const itemHeight = 35;
 const { options, children, maxHeight, getValue } = props;
 const [value] = getValue();
 const initialOffset = options.indexOf(value) * itemHeight;
 
 return (
 &lt;div&gt;
 &lt;List
 height={maxHeight}
 itemCount={children.length}
 itemSize={itemHeight}
 initialScrollOffset={initialOffset}
 &gt;
 {({ index, style }) =&gt; &lt;div style={style}&gt;{children[index]}&lt;/div&gt;}
 &lt;/List&gt;
 &lt;/div&gt;
 );
};
</code></pre>
The first thing we would like to see is performance improvement. This is the normal react-select rendering alongside the virtualized list one:
&nbsp;
<table>
<tbody>
<tr>
<td><img src="https://home.fasterthanlight.me/rails/active_storage/blobs/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBdDBCIiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--3ac32457a8f04ff0b4cb455a58df12f69b0bb64c/3.gif" alt="" width="536" height="455" /></td>
<td><img src="https://home.fasterthanlight.me/rails/active_storage/blobs/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBdDRCIiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--7fd3353b1be2fa99dfe6798752f65d6a1d74342e/4.gif" alt="" width="514" height="455" /></td>
</tr>
<tr>
<td>
React select 100 options
</td>
<td>
React select 10,000 options
</td>
</tr>
</tbody>
</table>
&nbsp;
The time to render with the virtualized list is almost the same as the list with 100 options. Also - the rest of the react-select functionality is enhanced: filtering options by value search, selecting an option or scrolling down the list. These were almost unusable before virtualizing the list.

<h2>React-window Shallow Dive</h2>
React-window solves the performance problem by virtualizing the list, and only rendering the visible items. At this point, it's important to note that mounting elements to the real (i.e non-virtual) DOM is the most expensive operation for the browser to perform. In order to avoid performance degradation, we will try to minimize the number of such operations.&nbsp; What does it look like in the real DOM?&nbsp; 
This is the DOM of the normal react-select options list:
<img src="https://home.fasterthanlight.me/rails/active_storage/blobs/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBdDhCIiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--bb1a74e55fd23fe3b63470b8e64973b2d6c959ae/5.gif" alt="" width="600" height="312" />
And this is the new DOM with the virtual list:
<img src="https://home.fasterthanlight.me/rails/active_storage/blobs/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBdUFCIiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--4eb440265b421729c29af007be1a48a1e23b60c9/6.png" alt="" width="600" height="304" /> 
The new DOM only has 9 list items. Of course, when scrolling down the list the items that are rendered change, but the amount of items remains 9 all the same. 
To better understand how this is achieved, we can inspect the react-window code. The key is a couple of methods called getStartIndexForOffset and getStopIndexForStartIndex:
<pre class="language-javascript"><code>getStartIndexForOffset: (
 { itemCount, itemSize }: Props&lt;any&gt;,
 offset: number
 ): number =&gt;
 Math.max(
 0,
 Math.min(itemCount - 1, Math.floor(offset / ((itemSize: any): number)))
 ),
 
getStopIndexForStartIndex: (
 { direction, height, itemCount, itemSize, layout, width }: Props&lt;any&gt;,
 startIndex: number,
 scrollOffset: number
 ): number =&gt; {
 const isHorizontal = direction === 'horizontal' || layout === 'horizontal';
 const offset = startIndex * ((itemSize: any): number);
 const size = (((isHorizontal ? width : height): any): number);
 const numVisibleItems = Math.ceil(
 (size + scrollOffset - offset) / ((itemSize: any): number)
 );
 return Math.max(
 0,
 Math.min(
 itemCount - 1,
 startIndex + numVisibleItems - 1 // -1 is because stop index is inclusive
 )
 );
 },
</code></pre>
The start index is calculated by the scroll offset, and according to the item's height. The stop index is fitted to the start index and is calculated by the provided height and item height. The visible items are inferred by the start and stop indexes, and rendered to the screen accordingly.
&nbsp;

<h2>Conclusion</h2>
React-select is a great choice for select components in React applications. We saw that the component might break for a large list use case, and also how to handle it. React-select is smart to provide a strong customization API, which should be a consideration when choosing an open-source component.
Moreover, we explained how to use react-window, as a very straightforward solution to handling large amounts of data, and rendering long lists efficiently.
The virtualization of list rendering can be used in many cases. Any time we would want to render a long list, we can utilize virtual rendering to enhance performance.

Our blog

Stay in touch