Open Licantrop0 opened 1 year ago
Hey there, thank you for the feature proposal! Unfortunately this is out of scope for the .NET Community Toolkit and just could not be added to it at all, as the proposed implementation has a hard dependency on several WinRT and WinUI 3 APIs (ISupportIncrementalLoading
, LoadMoreItemsResult
, IAsyncOperation<T>
), which are just not available from purely .NET projects at all. We'd need a dependency on WinAppSDK and WinUI 3 to access those APIs, and that's unfortunately not something we can do in the .NET Community Toolkit, as being completely framework-agnostic is one of its core principles. This API seems best suited for a separate package outside of the .NET Community Toolkit. Perhaps the Windows Community Toolkit might be a good fit for a proposal like this? 🙂
Hello Licantrop0, thank you for opening an issue with us!
I have automatically added a "needs triage" label to help get things started. Our team will analyze and investigate the issue, and escalate it to the relevant team if possible. Other community members may also look into the issue and provide feedback 🙌
Thanks for the issue @Licantrop0, wonder if this makes sense to be it's own class, if there should be a common base class, or should there just be another constructor on the IncrementalLoadingCollection
that takes the new interface?
Looks like we would need the https://www.nuget.org/packages/Microsoft.Bcl.AsyncInterfaces
reference for UWP support, but otherwise, should be able to make it work universally.
Another constructor on IncrementalLoadingCollection
would introduce some complexities (e.g. forking between _source and _asyncEnumerable all over the places) and the original class definition IncrementalLoadingCollection<TSource, IType> : ObservableCollection<IType>, ISupportIncrementalLoading where TSource : IIncrementalSource<IType>
would not make much sense for the IAsyncEnumerable implementation.
A base class could be a good idea, as they both implement ISupportIncrementalLoading
and they cater to the exact same scenario. However, considering the differences in the constructor and the way data is sourced, merging them into a single base might result in an architecture that's somewhat convoluted and harder to maintain, if the base contains a little more code than an Interface.
I can write a couple of proposals (extending the code above to implement all the other features like OnStartLoading
, OnEndLoading
, and OnError
), and then we can vote for the best one.
Overview
To implement an IncrementalLoadingCollection, you need:
CommunityToolkit.Common
namespaceMicrosoft.Toolkit.Uwp
namespace.The API design is quite dated and requires creating a source class implementing
IIncrementalSource<TItem>
, and creatingIncrementalLoadingCollection<TSource, TItem>
.IIncrementalSource requires to implement a method returning
Task<IEnumerable<TItem>>
that is modernly expressed withIAsyncEnumerable<TItem>
.IAsyncEnumerable<TItem>
allows cycling over the collection in a fully asynchronous way and it's the perfect fit for a modern IncrementalLoadingCollection. I called this new typeAsyncLoadingCollection
API breakdown
Usage example
Then you can bind myAsyncCollection to a DataGrid as ItemsSource
Breaking change?
No, it's an addition to IncrementalLoadingCollection.
Alternatives
After few days of research, I couldn't find any other implementation of an IncrementalLoadingCollection using IAsyncEnumerable.