Blazor Virtualize 22-25 items

[hannespreishuber]

extended Weatherservice to 500 records, added a ID property named Counter (incremented)
Changed fetchdata.razor

 <Virtualize Items="forecasts" Context="forecast">
                <ItemContent>
                    <tr @key="forecast.Counter">
                        <td>@forecast.Counter</td>
                        <td>@forecast.Date.ToShortDateString()</td>
                        <td>@forecast.TemperatureC</td>
                        <td>@forecast.TemperatureF</td>
                        <td>@forecast.Summary</td>
                    </tr>
                </ItemContent>
                <Placeholder>
                    <tr>
                        <td>Loading...</td>
                    </tr>
                </Placeholder>
            </Virtualize>

shows only 22-25 rows in Browser

• ASP.NET Core version 5 5.0.100-rc.1.20452.10

• Version 16.8.0 Preview 3.0

[GarettCooper]

I'm experiencing a similar issue. My chat log consistenly shows the last 24 messages, removing older messages when new ones are added to the virtualized items. I can make the number of messages change when I resize the div, but that sometimes results in elements overlapping each other and not appearing in the correct positions. I haven't tried implementing my own ItemsProvider to resolve the issue.

Screenshots

[mkArtakMSFT]

Thank you for filing this issue. In order for us to investigate this issue, please provide a minimalistic repro project (ideally a GitHub repo) that illustrates the problem.

[hannespreishuber]

no rocket science.- but https://github.com/hannespreishuber/Blazor5App

[SteveSandersonMS]

@GarettCooper I think your issue is different and may be due to some unwanted interactions between CSS and <Virtualize>. If you could file a new issue with minimal repro steps we can take a look.

In fact looking at your screenshots, it appears that the items in your list aren't of a fixed equal height. The <Virtualize> component in 5.0 requires items to be the same height as each other, because otherwise it can't compute where in the list you are if the user scrolls suddenly right into the middle of the list.

We are tracking support for variable-sized items in a future release at #26099. In the meantime, instead of using <Virtualize>, if your items do have to vary in height then you should look at implementing your own separate infinite-scroll style behavior.

[SteveSandersonMS]

@hannespreishuber Thanks for the repro information. I was able to observe this issue and have tracked down the underlying cause.

The issue happens when <Virtualize> recomputes its estimate for the item height, and it happens to be so similar to the default value that it thinks no re-rendering is needed. Then it doesn't refresh while the user is scrolling because it's no longer listening for events.

Workaround

If you want to work around this in your own code, it's reasonably easy. You just need to pass an accurate ItemSize parameter to the <Virtualize> component so it will use your value instead of its default initial value of 50px. When I ran your code, I used the browser dev tools to see that the actual item height is 48.89 pixels:

So then I supplied this information to <Virtualize>:

<Virtualize Items="forecasts" Context="forecast" ItemSize="48.89f">
    <tr @key="forecast.Counter">
        ... etc ...
    </tr>
</Virtualize>

... and now it behaves correctly and doesn't get stuck.

If you don't like relying on arbitrary-seeming values like 48.89, then it's probably best to use CSS to force the items to be a specific known height. For example in your .css file you could set .my-table td { height: 50px; } or similar, and then you know to pass ItemSize="50".

Fixing it in the framework

I have prepared a fix for <Virtualize> that lets it detect when a refresh is needed purely due to changes in the item size estimate. However I don't know yet whether we will include this fix in the 5.0 release because the bar for including changes now is quite high and this issue has an easy workaround. I'll post an update here later when we have a decision about that.

[hannespreishuber]

If you don't like relying on arbitrary-seeming values like 48.89, then it's probably best to use CSS to force the items to be a specific known height. For example in your .css file you could set .my-table td { height: 50px; } or similar, and then you know to pass ItemSize="50".

Thanks - I can live with that workaround, as I want to support blazor to reach the best tool, missing size is unexpected behavior. Needs a remark in docu and/or a warning in Visual Studio of missing size attribute on compile.

[GarettCooper]

@SteveSandersonMS Thanks for letting me know, the height issue did occur to me but I couldn't find any documentation confirming or denying that Virtualize only supported items with consistent heights. When I saw Virtualize in the blog post I was hoping for a silver bullet, but I guess I'll have to look in to writing my own solution.

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

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