Feature Request: Support both width and height in Blazor Virtualize

[wwarby]

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

I am trying to display several thousand image thumbnails in a grid layout with Blazor and virtualize scrolling through the thumbnail gallery to improve performance.

Describe the solution you'd like

The ability to set both the known width and height of the elements within a <Virtualize> component in Blazor, and have the virtualization take into account multiple items per "row", whether the number of items per "row" is dynamic based on the available width of the container and the provided ItemWidth. Something like this:

<div>
  <Virtualize Items="@images" ItemWidth="200" ItemHeight="200">
    <div style="display: inline-block; width: 200px; height: 200px;">
      <img src="@context.Url" />
    </div>
  </Virtualize>
</div>

Additional context

Apologies if this is somehow already possible and a couple of hours of Googling hasn't led me to the answer - I'm new to Blazor.

[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.

[SteveSandersonMS]

Thanks for the suggestion.

Because of the complexity of implementing this, I think it's unlikely that we'll extend <Virtualize> to support simultaneous 2-dimensional scrolling any time soon. We would only attempt that if it becomes a very common request. Sorry about that!

We'll leave it on the backlog.

[wwarby]

Thanks for the response - just in case I misrepresented the requirement, I want to be clear that I didn't mean for a horizontal scrollbar to exist, only that it would be possible for items be placed side by side and wrap onto the next line. In other words think like how Windows Explorer works in "Large Icons" mode - so if each "tile" is a defined to have a fixed width and height, the grid would fit as many tiles horizontally as the container can take, then wrap onto the next line, and the virtualizer would be aware of the tile width and container width such that it can figure out how many tiles naturally fit on each row in addition to how many rows fit in the container.

I'm not suggesting the requirement is simple to implement by any means, but as an example this Angular virtualizing plugin supports this requirement and I believe WPF's VirtualizingWrapPanel does more or less the same job, so it's definitely not outside the normal range of features for a virtualizing panel. I have actually switched my project now from Blazor to Angular, principally because I couldn't find a suitable implementation of this exact requirement for Blazor and didn't fancy writing one myself.

The use case is a "thumbnail gallery", or any scenario in which "tiles" of known width and height are arranged in a responsive grid - it isn't probably as common as the full row scrolling list use case, but I'd argue it isn't exactly a fringe requirement either.

[SteveSandersonMS]

Thanks for clarifying, @wwarby. That is quite different from the arbitrary 2D scrolling behavior I thought you meant before. But it is complicated in its own ways, as we'd have to bake in a mechanism for computing how many items would be on each row, and dealing with changes to that.

[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.

[msynk]

I think it's a useful feature as other frameworks have it working seamlessly like the list components in the Microsoft Fluent UI library:

https://developer.microsoft.com/en-us/fluentui#/controls/web/list

[wwarby]

This is still the blocking issue for me that makes switching to Blazor impossible. My current setup is an Angular app running in Chromely in a native window, which is just cumbersome to maintain. I'd love to replace it with Blazor on MAUI but for my use case performance is unacceptable without wrapping virtualisation panels.

[rparussel]

Please, would you post an update of the progress of this issue? This has become a problem for a project I'm working on since we upgraded from .NET 5 to .NET 6. I notice that bitfoundation/bitplatform#1880 has been closed with the comment, "Since we decided to apply another approach to resolve this issue, I'm closing this PR."

[msynk]

another seamless and complete implementation of the virtualization can be found in the BlazorFluentUI library. they've implemented their own virtualization.

check the demo here:
https://www.blazorfluentui.net/listPage

check the source code here: https://github.com/BlazorFluentUI/BlazorFluentUI/blob/main/src/BlazorFluentUI.CoreComponents/List/List.cs

[rparussel]

another seamless and complete implementation of the virtualization can be found in the BlazorFluentUI library. they've implemented their own virtualization.

Thanks for the recommendation. According to github, this only has maintenance only support, which makes us a bit nervous about developing a solution that depends on this. I'll see if we can tweak the settings of the standard Virtualize to get it to work better.

[msynk]

Thanks for the recommendation. According to GitHub, this only has maintenance-only support, which makes us a bit nervous about developing a solution that depends on this. I'll see if we can tweak the settings of the standard Virtualize to get it to work better.

oh, I'm not suggesting using that particular component library. I was just mentioning that somebody else has already implemented the complete virtualization in a blazor project. they don't have a Virtualize component per se. you can check their source code and try to implement your own complete Virtualize component instead of using Blazor's default one.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 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.

[mkArtakMSFT]

After further discussion we've concluded that this ask is about bringing support for wrap-style list (multiple items per row) and given a fixed width we can potentially do this.

[Gareth064]

Thanks for the suggestion.

Because of the complexity of implementing this, I think it's unlikely that we'll extend <Virtualize> to support simultaneous 2-dimensional scrolling any time soon. We would only attempt that if it becomes a very common request. Sorry about that!

We'll leave it on the backlog.

Hi @SteveSandersonMS. Sorry to bring up relative old subject again. But what about extending the <Virtualize> component to allow either Vertical or Horizontal virtualized scrolling, but not both?

Common use case for Horizontal virtualized scrolling is with a typical Timeline View inside a resource scheduling component. You have "Resources" on the Y axis (very unlinky to need to virtualize the scrolling on that unless you have 100's and 1000's of resource to render) and "Dates" on the X axis. And as you scroll left and right, it will render only the dates\data (for the resources) that you can see on the screen.

Here is an example of such functionality in a JavaScript based app.

Useability.mp4

Happy to raise a new issue for this particular request if you think it would go anywhere.

[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.