Blazor Virtualize: Empty Rows Template

[jlchavez]

Currently when the ItemsProvider returns zero count it will display nothing, an EmptyContent template would improve the usability for the end user so that it knows that there is no data and the loading has been completed. This would reduce workarounds as checkinf if the ItemsProvider has returned Total Rows = 0, adding conditions to display this message and calling StateHasChanged() so that it can be repainted.

@typeparam TItem
<table><tbody>
    <Virtualize Context="item" ItemsProvider="@LoadData" TItem="TItem">
        <Placeholder>
            <tr><td><p><i class="fas fa-spin fa-spinner"></i> Loading...</p></td></tr>
        </Placeholder>
        <EmptyContent>
            <tr><td><p>No data available</p></td></tr>
        </EmptyContent>
        <ItemContent>
            <tr @key="item">@RowTemplate(item)</tr>
        </ItemContent>
    </Virtualize>
 </tbody></table>

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

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

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.

[szalapski]

@jlchavez, @pranavkm, and others, I think an EmptyContent template might make sense when using an ItemsProvider, but I'm not so sure adding a EmptyContent is a real improvement over a conditional in the more common case of using the Items parameter. In the interest of keeping the component more focused, are we sure we want this feature? Part of the elegance of this component is that it is a drop-in replacement for a @foreach block with very little other features to possibly confuse or be concerned about.

In the case of not using an ItemsProvider, are you are advocating for:

<Virtualize Context="item" Items="Data">
    <EmptyContent>
        <tr><td><p>No data available</p></td></tr>
    </EmptyContent>
    <ItemContent>
        <tr @key="item">@RowTemplate(item)</tr>
    </ItemContent>
</Virtualize>

...over the current equivalent:

@if (Data.Any()){ 
    <Virtualize Context="item" ItemsProvider="@LoadData" TItem="TItem">
        <tr @key="item">@RowTemplate(item)</tr>
    </Virtualize>
}
else {
     <tr><td><p>No data available</p></td></tr>
}

I think I'd prefer the latter.

[jlchavez]

I would say that good developers follow development principals that will make code cleaner, efficient and less prone to errors, and a good example is the DRY principle, dont't repeat your self. That's why we have components like Virtualize that reduce complexities, without having to copy/paste spaghetti code.

Adding the EmptyContent and a LoadingContent would remove duplicating code in every grid in your app, but you can still do it the coded way if you like to.

[szalapski]

Are you saying the example I gave above has duplicated code? Or is there another example I can look at that illustrates your point?

[thalaeg]

@jlchavez, @pranavkm, and others, I think an EmptyContent template might make sense when using an ItemsProvider, but I'm not so sure adding a EmptyContent is a real improvement over a conditional in the more common case of using the Items parameter. In the interest of keeping the component more focused, are we sure we want this feature? Part of the elegance of this component is that it is a drop-in replacement for a @foreach block with very little other features to possibly confuse or be concerned about.

In the case of not using an ItemsProvider, are you are advocating for:

<Virtualize Context="item" Items="Data">
    <EmptyContent>
        <tr><td><p>No data available</p></td></tr>
    </EmptyContent>
    <ItemContent>
        <tr @key="item">@RowTemplate(item)</tr>
    </ItemContent>
</Virtualize>

...over the current equivalent:

@if (Data.Any()){ 
    <Virtualize Context="item" ItemsProvider="@LoadData" TItem="TItem">
        <tr @key="item">@RowTemplate(item)</tr>
    </Virtualize>
}
else {
     <tr><td><p>No data available</p></td></tr>
}

I think I'd prefer the latter.

I think your examples are mixing up the two. The second one using the ItemsProvider wouldn't have Data before querying. So that is why the EmptyTemplate is better inside.

If instead you meant for it to say Items (and therefore comparable examples) I think the EmptyTemplate (aka the first example) way looks cleaner.

The Virtualization component should have everything it needs to tell if it is empty or not, why not give that data back to a user to choose to use or not.

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

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