Don't unload rows when scrolling under certain situations
See original GitHub issueIf my list is 10000 items long, then react-virtualized works great! It loads fast with the downside that fast scrolling causes you to scroll past some blank rows until you slow down and let the renderer catchup. The blank rows are more pronounced if your rows are DOM heavy. This is a fine tradeoff.
What I noticed is that if my list happens to be only 100 items long, react-virtualized is overkill. So, I could look at the size of my list and if it’s long, render it using react-virtualized, and if it’s short rendering it without, but this adds a complex switch into my app. So, what I do instead is pass a big number to overscanRowCount
if the list happens to be short. This causes it to render the whole thing from the start (which is a bit slower), but I don’t get any flickering when scrolling. It works pretty good.
I have an idea for getting rid of that “a bit slower” thing. Right now, if you scroll down, react-virtualized will load a row at the bottom and unload a row at the top. What if you added another prop like maxBufferRows
that says how many rows to keep before unloading them? So, if I set this to 100, then react-virtualized would initially load (lets say) 20 rows and then as I scroll down it adds rows one by one until it gets to 100 and only then does it start unloading rows at the top.
This way, if I have a short list, I get the best of both worlds: Fast initial render, less flickering when scrolling. If I have a long list, then it works like a normal virtualized list.
I think I may be able to implement this by implementing a complex overscanIndicesGetter
but I thought you might consider this for inclusion by default.
Issue Analytics
- State:
- Created 6 years ago
- Comments:5 (5 by maintainers)
Top GitHub Comments
Like you said, its easy enough to track the prev values myself. In case you change your mind:
https://github.com/offsky/react-virtualized/commit/dd6ad703a79a35a8de9c3d28aef1e372812d689a
Hm… I don’t think I’m a fan of
Grid
passing in prev values FWIW. Seems better (and easy enough) to track in your callback function.