Blazor Wasm: Virtualize component making 3 initial calls to ItemsProvider instead of 1

[bancroftway]

When using Virtualize component with ItemsProvider, I have noticed that the ItemsProvider is always called 3 times on the first render. This may be slightly excessive if we are calling an api inside the ItemsProvider.

As an example, I have a collection of 15000 items. On first render, the Virtualize component made 3 calls into the ItemsProvider:

1. Request Count=20, Start Index=0
2. Request Count=21, Start Index=14979 (=15000 - 21)
3. Request Count=21, Start Index=0

I am guessing that the component is doing this for some initial setup calculations of the scroll bar etc...however, the question is whether these 3 calls can be obviated by a single initial call, or is there a way to specify any additional arguments to the component perform its setup without performing 3 calls into ItemsProvider.

Reproduction is here: https://github.com/bancroftway/blazorissuesrepro/tree/dotnet5vscoll

A small video demo is here: https://www.youtube.com/watch?v=5BnRgZTpO0M

[ghost]

Thanks for contacting us. We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[mrlife]

I can confirm something similar is happening on Blazor Server. The ItemsProviderRequest content is unexpected.

For a collection of 107 items, it varies:

1. Request Count=11, Start Index=0
2. Request Count=80, Start Index=27
3. Request Count=116, Start Index=0

And

1. Request Count=11, Start Index=0
2. Request Count=54, Start Index=53
3. Request Count=115, Start Index=0

Since my Virtualize contains EF Core code in a descendant component, I get the "A second operation was started on this context before a previous operation completed" unless I save the return value of the first call and return it for calls 2 and 3.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[umairtkxel]

Facing the same issue in .Net7 Blazor WebAssembly