Rows in <List> unmount and then mount when they leave the active window

[benthehenten]

Thanks for the awesome library!

I noticed some strange behavior with the List related to the overscanRowCount setting. Let's say there are 10 rows visible and overscanRowCount is set 10. When I scroll the list such that a row leaves the visible region, but is still within the overscan radius, the component is unmounted and then instantly re-rendered. This is an issue since it causes unnecessary re-renders and resets the local state of the components as they leave the screen.

If this is indeed a bug, and not expected behavior, I'd be happy to code up a minimal reproduction and help work toward a fix!

Thanks!

[bvaughn]

You're welcome. 😄

When I scroll the list such that a row leaves the visible region, but is still within the overscan radius, the component is unmounted and then instantly re-rendered.

When at rest, react-virtualized overscans equally in both directions. For example, if your List is tall enough to show 10 rows and you set overscanRowCount to 5, a maximum of 20 items will be rendered (5 above, 10 within, and 5 below). Once a user starts scrolling, react-virtualized adjusts the direction it overscans in to match that being scrolled. For example if you begin scrolling down, the List will still contain a maximum of 20 items (10 within and 10 below). This helps reduce the flicker near the edges of the screen when a user is scrolling quickly. Once a user stops scrolling then react-virtualized will return to its resting state (5 above, 10 within, and 5 below).

So what you've said to me sounds more or less expected. I believe when you say that a row is "instantly re-rendered" you are referring to the fact that overscan shifts back to above/below once scrolling stops. This is by design.

This is an issue since it causes unnecessary re-renders and resets the local state of the components as they leave the screen.

You might be aware of this, but just to be completely clear- components will not retain state once they've left the viewport. This is a limitation of windowing with react-virtualized (or similar libraries). Any "state" that should persist should be stored externally (eg within the underlying List/Array, in Redux, in the parent component's state, etc).

I don't think there's any bug here so I'm going to close this issue. If I have misunderstood your report though, or if you have any additional questions or concerns, just leave a comment. (I'll still get notifications on the closed issue.)

[bvaughn]

I put together an image to illustrate what my previous comment meant about over-scanning (in case it's any clearer or more helpful):

The left-most List is at rest. The middle one is being scrolled down and the right one is being scrolled up.

[benthehenten]

Makes sense-- thanks for the detailed explanation!

[benthehenten]

Having now implemented my list, I think that the optimization of unmounting rows in the opposite direction of scroll may be detrimental to UX. In my app, a typical user behavior is to scroll back and forth between 2 rows to compare them. Often, the rows are slightly farther apart than the height of the viewport, and when the user scrolls down to one row, and immediately scrolls back up to the other, there is some flicker.

If overscanRowCount simply kept n rows above and below the viewport rendered, I think it would solve this problem. However, I do understand the rationale for the current implementation. Is there currently a way to force this behavior without forking?

I'm not sure if this would be a popular feature, but I would like to be able to customize the behavior of overscan by passing in a function shouldRenderRow that looks something like ({ index: number, distanceFromViewport: number }): boolean.

[bvaughn]

Hmm. Based on my own testing as well as user feedback- I'm fairly confident that the recent overscan change resulted in an improved UX. There may still be some flicker if the scrolling direction changes rapidly- but it should be minimal. (And unless a user reverses scroll direction within 150ms, overscanning resets anyway.)

No. There's no way to customize this currently. You could perhaps override the cellRangeRenderer prop and add N rows before but that would be a bit hacky.

I am a little doubtful that the cause of the flicker is what you think it is, but I could be wrong. Is this somewhere I can take a look at? 😄

[IanVS]

Is there a benefit to removing the "trailing" rows? I don't understand all of the performance considerations very well, but I wonder if it might be more flexible to add another prop like additionalScrollOverscan which would just add the specified rows to the overscan in the direction of a scroll, while still maintaining the original overscan in both directions.

[bvaughn]

Is there a benefit to removing the "trailing" rows?

Limiting the total number of rows rendered. This matters more when there are overscanned rows and columns b'c the number grows faster.

[IanVS]

Makes sense. I suppose it could still be made configurable (the number of rows/columns to move from trailing to leading overscan). But maybe it's not worth the extra prop.

[bvaughn]

True, it could, but every configurable property has a cost (in runtime complexity, code management complexity, API complexity/understandability, etc.)

In this case, I'm not really convinced that the cost is justified. I could change my mind though. :)