overscan direction = both

Overscan (#64) helps UX a lot when cells contain slowly rendered graphics. However, when a user suddenly changes scroll direction, flickering still occurs. This happens because the cells are deleted immediately after going even by 1 pixel beyond the screen.

Some exploration tasks expect users to navigate around a virtual grid in unpredictable directions to perform visual comparison between objects or features. It would help a lot if developers could tell react-virtualized to keep cell cache in both directions when needed. This could be something like overscanBothDirections={true} or reverseOverscanColumnCount={42} + reverseOverscanRowCount={43}.

What do you think?

[kachkaev]

Hi again @bvaughn,

Check out this MWE:
https://kachkaev.github.io/react-virtualized-overscan-direction-issue/

Source:
https://github.com/kachkaev/react-virtualized-overscan-direction-issue/blob/master/src/App.js

When you scroll in one direction, the cells almost always render outside the viewport, because overscanRowCount=2. However, when you suddenly decide to scroll back, you start seeing green or red artifacts while the tiles or SVGs are being prepared. reverseOverscanRowCount={N} could solve this negative visual effect.

The problem I was able to reproduce in the demo is not as severe as in the real app I’ve been making. I’ve got WebGL maps with vector tiles in there and the components require 0.5-1 sec to warm up. MapboxGL.js has some issues with webpack, so I could not fit it into create-react-app for the demo (it works OK with react-boilerplate, but that would make the MWE too bulky).

Would be glad to know what you think! The visual effect that’s being observed at the moment makes it harder to perform data exploration and certain cognitive comparison tasks and it’d be great to escape this problem somehow.

[ivanalejandro0]

Do you think that we can have this new property (overscanIndicesGetter) on the List as well? I guess it could be passed through to the Grid like is done with overscanRowCount.

P.s.: This is great news!, I wanted to avoid the extra cpu consumption when the scroll direction is changed on small devices and this is what I needed to achieve it. Thank you very much!