I'm seeing a lot of white while scrolling (screen cap below) in a list of 3xx items. They're all connected items, though (as in they're bound to a store), does this make a difference? Are elements re-created or cloned in order to virtualize them? I don't have that problem in the react-window demos, and they seem to have tons of items more, i wonder what's causing it for me ... 🤔

And a quick screenshot of the code that produces the list:

My first question about the above screen cap is: Is it running in development mode? Because DEV mode is _significantly_ slower than production (due to extra validations and warnings, unminified/unoptimized code, etc.)
How far ahead of the scroll handler you can get when quickly scrolling– (i.e. how much blank white space you see) is not really related to the number of items in the list. It's totally a matter of how fast the scroll handler can run when creating and inserting new DOM elements. I'm not sure how much overhead there is in the @subscribe function that "connects" your components, but I'd start by trying to move that out/up if possible so that each individual item is lighter weight. (You might also want to verify that your ListItems are memoizing correctly and not re-rendering on each scroll because of something to do with the @subscribe function).
You're also doing some array manipulation and mapping. This should be pretty fast, but you might consider experimenting with a scroll indicator to render a lighter-weight version of yours rows _while scrolling_ to save more time.
But in general, this is just a limitation of windowing. The only way to ensure that there is _no_ empty space when scrolling is to force scrolling to run on the main/UI thread. The downside of this is that longer renders will make the UI jerky and less responsive to user input. I think some blank space around the edges is a better trade off.
Going to close this issue for now because it's not really actionable 😄 Hope the above response was helpful though!
@bvaughn Thanks, very helpful!
Just one more question that i have, i logged componentDidMount and indeed, items do re-mount all the time. Now they'd go through a redux-like subscribe that binds them to a context store. I could imagine this is some overhead. The problem i have is that the list can get huge, say 100.000 items. And they all change status (done: false -> true) asynchroneously. If i would bind the list control to the tasks, it would re-render countless of times, this is what i wanted to avoid when binding list-items individually. Is there anything react-window could help me with? Like telling me which items are being displayed, etc? How do people in general solve such issues (large lists where items change state)?
List does provide an event, onItemsRendered, which is called whenever the items rendered by the list change:
function onItemsRendered({
overscanStartIndex,
overscanStopIndex,
visibleStartIndex,
visibleStopIndex
}) {
// All index params are numbers.
}
You could use this event event to keep track of which items are currently visible (and maybe store that info in state).
You could also pass the subscribed data from your ItemList component to your ListItem via the itemData key. (You might find this react-window integration useful to look at, although it's advanced.)
This might take a bit of playing around with to get right, but it should be possible 👍
Awesome, thanks a lot, this will do! 😃
Keep me posted if you learn anything new that could help improve the docs or be added to a new Code Sandbox example etc 😄
@bvaughn, Quick question. So if I am facing this issue it means I should refactor my row component and I should not do any calculation or data manipulation in my row component for fast rendering or we can say for getting rid of white spots on scrolling a little bit fast in the list. :thinking:
Please let me know. I think I am facing this issue because I am doing a little bit of calculation on the basis of the row index. Maybe. :innocent: