Virtualization: avoid dependency on specifying exact ItemSize

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]

@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).

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