Virtualization: avoid dependency on specifying exact ItemSize

[SteveSandersonMS]

Summary

We should try to make <Virtualize> more tolerant of incorrect ItemSize values, and possibly even make that parameter optional.

Motivation

The initial version of <Virtualize> requires an ItemSize parameter. It's quite common to get the value wrong because:

• CSS is tricksy. Even if you specify .my-item { height: 50px; } the actual height might be something else like 50.25px if there's a border and you're not using box-sizing: border-box.
• The developer updating CSS is often not the same as the developer writing .razor components. You can't count on them absolutely staying in sync.
• If you have a CSS media query, the item height might actually vary between different devices, so there isn't even a single ItemSize you can get right everywhere.

Currently, if the developer gets the ItemSize wrong, the behavior of <Virtualize> is undefined and can do some pretty wild things, including "movements of the scrollbar don't line up with movements in the UI" and "infinite loop of fetching and rendering alternate sets of data".

Goals (prioritized)

1. Ideally, developers should not have to think about specifying ItemSize at all, and it would just be an optional thing they can do if they want to get more optimial behaviors. We would silently figure out the right value, and only use the developer's specified value as an initial hint until we discover the true value.
2. Or if it remains mandatory, we should ensure we don't behave too badly when the supplied value is a bit wrong
3. Or if we can't do that, then we should detect wrong values and issue a warning or error

Non-goals

• Handling heterogeneous item sizes within the list
• Handling item sizes changing dynamically (e.g., because of CSS media queries kicking in when a user reorients their device)

... because these would be very difficult and might force us to make losses on perf, for example by rechecking the rendered size of every item after every render, or maybe having to poll for changes in case they are made by CSS media queries dynamically.

Scenarios

This applies in all scenarios where <Virtualize> is used, i.e., to optimize the fetching and rendering of large lists/tables of data. Hopefully no new API surface is required.

Risks

It's possible that we might leave developers thinking <Virtualize> is more magic than it is. If they're not specifying ItemSize, they might believe/expect it can handle heterogeneous sizes, and we most likely don't have any way of detecting if they are rendering heterogeneously-sized items (except by brute-force checking, which might be bad for perf).

Interaction with other parts of the framework

Doesn't interact with anything outside <Virtualize>.

[SteveSandersonMS]

Possible implementation: after the first render in which we rendered a non-placeholder item, make a JS interop call that returns the offsetHeight of that item. If it's different from the ItemSize we were given, update the internal state and re-render. If no ItemSize is specified, default to something general like 50px. I don't know how well this would work in practice.

[radderz]

@SteveSandersonMS is there any way for Blazor to do this for lists where the item size isn't the same for each row, even if the performance isn't great? Could that be a different Virtualize feature in the future? Sometimes we need to be able to virtualize uneven rows like in the Xamarin version of their ListView. Wildly different uneven rows aside, if there is the odd row that is slightly different due to having an extra line of text I would have thought an approach would be possible even if non great perf wise. In long lists of this type of content a perfect match of the rows that should be visible vs the position of the scroll bar isn't super important so long as it realigns itself later by adding/removing bottom/top padding depending on how far through the list you are.

This seems to be a common missing capability in web frameworks and the only alternative seems to be in lazy loading and slowly growing the list instead of a full virtualization.

[SteveSandersonMS]

@radderz Theoretically that could be added in the future but it's not in scope for the initial release. There are are lots of subtle UX design questions to be answered to make heterogeneous sizes work well, if it's possible at all (e.g., extreme edge cases like a 1000-item list where all the items are 20px tall except for just the 600th one which is 10000px tall).

[radderz]

@radderz Theoretically that could be added in the future but it's not in scope for the initial release. There are are lots of subtle UX design questions to be answered to make heterogeneous sizes work well, if it's possible at all (e.g., extreme edge cases like a 1000-item list where all the items are 20px tall except for just the 600th one which is 10000px tall).

There is also the situation of updating content within that list potentially changing the shape of some items. I would have thought something like an estimated row height, which just assumes all rows that are not rendered on the dom are of an set height, and then adjusting the padding on top and bottom of current viewable items to keep it reasonably in sync.

Should I create a separate issue as a feature request for a future release?

[SteveSandersonMS]

Should I create a separate issue as a feature request for a future release?

Yes, by all means please do file a separate issue that we can keep on the backlog. Alternatively you might want to have a go at implementing this yourself and publishing it as a separate package to validate whether a good implementation is really possible and whether or not there's demand for it.