search

bvaughn / react-window

React components for efficiently rendering large lists and tabular data
https://react-window.now.sh/
MIT License
15.54k stars 779 forks source link

Bidirectional `overscanCount` for `FixedSizeList`? #678

Open kevinjmo opened 1 year ago

kevinjmo commented 1 year ago

Quoting @bvaughn from #111 here:

I'll think on it a little. In the past at one point, I did use overscanCount in both directions– but I changed it to only be used in the forward direction so I could reduce the amount of scripting time was spent in perf sensitive "scroll" handlers. Although if the memoization is solid, this shouldn't have much of an impact so maybe it wouldn't hurt too much to change back... I'll want to think on it some more.

Any chance we could revisit this? I think there’s a valid use case for this. Looking at the current source code, I see that there’s the bidirectional overscan when it is not scrolling, but as soon as it scrolls, it’s set so that the opposite direction uses 1 instead of overscanCount https://github.com/bvaughn/react-window/blob/d80bef25fe706d0c73fc801674c086f681811190/src/createListComponent.js#L507-L516

Even if it’s not the most performant, at least making this an optional prop that can be enabled would be nice?

CC: @austincondiff @lambrospetrou @zackasaurus

matko-antunovic commented 1 year ago

Is there any alternative way of handling this? I haven't been able to come up with anything nor did I found any other solution..

lambrospetrou commented 1 year ago

Just as another datapoint, I did implement similar changes to https://github.com/bvaughn/react-window/pull/220 in my team's project back then, and it worked amazingly well. No perf issues at all, and the user experience was much better than the default where if you change direction you end up in a "white/empty" block until rendering happens, and it even avoids rendering the same rows over and over.

matko-antunovic commented 1 year ago

@lambrospetrou Thanks a lot, I'll take a look!