overscanning kicks in *after* the user scrolls in either direction?

(I’m happy to post GIF of Chrome’s paint-flashing debug should you not understand the case)

In a nutshell, I specified x overscanCount, and I was expecting to have x rows (pre)rendered top and bottom of List at all times. That way when the user suddenly changes scroll direction from up to down or vice versa, there is literally no flash of unstyled content.

AFAIK, react-window does overscanning in one direction only and that direction is determined once the user starts scrolling in the said direction. First scroll event that is. Due to which, the “repaint” happens in the visible viewport which isn’t that pretty.

[austincondiff]

Any movement on this issue?

I agree that while this isn’t a common use-case, it is still a use-case and while it increases the amount of scripts run, as mentioned memoization should negate this concern.

My argument is that in applications where attention UX is critical, things like this stick out like a sore thumb and make things look broken.

I don’t see any harm in at least allowing for this behavior either by specifying a reverseOverscanCount amount or setting a birdirectionalOverscan to true.

[bvaughn]

That’s a reasonable suggestion, but it would also add complexity since list and grid would need to now track some extra state to know (a) when to preserve these backwards rows and (b) when to throw them out if e.g. props changed.

It’s worth giving some thought.

For what it’s worth, we hope to add more support for windowing to React core in the near to medium future. So some behaviors like we’re talking about might be moved into the framework.