[Feature] Provide a configurable data source for XAML list controls that implements random access data virtualization

[lukeblevins]

Effortless Use of Random Access Data Virtualization

This feature would allow users to easily leverage the IItemsRangeInfo and ISelectionInfo interfaces for random access data virtualization without having to re-implement it themselves.

For instance, users frequently report that certain WinRT APIs like Windows.Storage are slow to return many items compared to their Win32 equivalent, but they like having the extended properties which come from StorageFile. This solution would allow them to use a custom data source, specifying the base collection of items retrieved from, say, a FindFirstFileExFromApp() call. Afterwards, we should be able to handle when a user scrolls different items into view by (example) fetching the "extended" properties of the item like Thumbnail from somewhere other than the base collection.

How specifically?

In other words, when a user scrolls new items into view, the data source should-for the entire visible range-fire an event that users can handle by fetching the extended properties and updating the item in-place. This event handler should have an argument of the item itself (castable object) which the user can utilize when checking for/setting unset properties.

Alternatives considered

• The Windows.Storage.BulkAccess APIs which return a virtualized vector: These are acceptable, but hard to implement and lack support for items with non-normal attributes like shortcut and hidden. I also figured this approach would enable additional scenarios which require this type of data virtualization.
• Implementing the interfaces myself: This is relatively difficult to get right and seems like this could be abstracted for novice users.
• Not using the lower level virtualization: This is a bad approach because it wastes resources loading many unnecessary items.

Additional context & Screenshots

I am essentially asking for an abstraction of the sample detailed here: https://github.com/microsoft/Windows-universal-samples/tree/master/Samples/XamlDataVirtualization

Later on, we could add support for IItemsRangeInfo to DataGrid, but that control is currently in maintenance mode. All in all, this data source would be designed for ListView and GridView.

[ghost]

Hello, 'duke7553! Thanks for submitting a new feature request. I've automatically added a vote 👍 reaction to help get things started. Other community members can vote to help us prioritize this feature in the future!

[michael-hawker]

Thanks @duke7553 for the feature idea. I think this is a slightly different scenario than our existing Incremental Loading Collection, correct?

This is more about these things are already loaded to some degree, but could be 'enhanced' with more details as cycles permit?

Or could this be an extension to the incremental loading helper to have it better support these scenarios?

Thoughts @vgromfeld @Sergio0694?

[lukeblevins]

@michael-hawker This would be different from the existing Incremental Loading Collection because it would start out with every item present (perhaps a placeholder or partial storage item) and fire an event when the visible ranges are updated. Rather than loading entirely new item containers when scrolling downwards, they are already present and we would perform an action to update the items in the viewport.

IItemsRangeInfo would allow ListView and GridView to interface with our data source this way.

[michael-hawker]

Thanks @duke7553, we have the ViewportBehavior too which does some of this, but in a different way. So seems like we'd be looking for an easier to use more general solution for the collection control itself.

Trying to think how this scenario works with ItemsRepeater and how we'd differentiate how to use each solution.

I could also see this tying into the discussion on the WinUI repo about Placeholder Content UI. This is almost like a more specialized version of that in some ways. It could make sense to pull that in as a first step and experiment broadly in the Toolkit with both these features while WinUI 3 work is continuing.

[lukeblevins]

@michael-hawker Nope. It looks like the docs claim these interfaces have no effect on ItemsRepeater:

I guess if we need to support the ItemsRepeater, then microsoft/microsoft-ui-xaml#374 is a pre-requisite for this issue.

[michael-hawker]

@duke7553 that's ok, I think we could still figure something out for ListView/GridView. We should just keep an eye on that other issue for ItemsRepeater for the future. 🙂

[Janisku7]

might be something underlying issue there but yeah could be good for figure out for ListView/GridView so if the thing is similar what give no affect on Itemsrepeater then we could solve it that way too