Virtualize and displaying content at the end of the list

[JamesNK]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Scenario:

• Page displaying a list of live results.
• New results are added to the list, with the oldest at the top of the list and newest at the bottom.

When the page loads, we want to show the newest results. That means the scroll position is the bottom of the container. There isn't a built-in feature to do that in Virtualize, so it means loading initial data, virtualize renders the contents with spacers, then using JS interop to scroll to the bottom of the list. That then loads and renders content again.

A similar problem exists when data is added to the list after the page has loaded. Virtualize loads data and renders, JS interop runs to scroll to the bottom of the list and Virtualize loads data and renders again. This is inefficient and it looks like it causes content to flicker as it is added to the list.

Describe the solution you'd like

There should be a way to say to Virtualize that you want to view the end of the list, both when loading and when adding new data. It should be efficent and there isn't flickers of content when loading/adding data.

Additional context

No response

[SteveSandersonMS]

The browser has a built-in concept related to this: https://developer.mozilla.org/en-US/docs/Web/CSS/overflow-anchor. Even with the native overflow anchoring shown in that MDN demo, there is still some pixel-level flickering going on.

By default, Virtualize explicitly disables overflow anchoring because otherwise it can get into an infinite rendering loop.

It might be that overflow anchoring is a good long-term solution if we could find a different solution to the risk of an infinite render loop. But in the short term maybe this could be refined:

virtualize renders the contents with spacers, then using JS interop to scroll to the bottom of the list.

Is this the logic you're using? If so you already have the power to modify the scroll position synchronously whenever the DOM is updated, so you are already able to change it just as fast as Blazor could do.

I don't personally have experience with using ResizeObserver and am more familiar with MutationObserver. As I understand it, MutationObserver callbacks run synchronously as part of DOM mutations, and so there should be no time delay (or intermediate UI painting) between the DOM updates and the scroll position updates. Not sure if the same is true for ResizeObserver.

[JamesNK]

I'll make time to reply. Busy with other things right now.