NotifyCollectionChangedAction: SourceCache vs ObservableCollection

[CodingOctocat]

• Collection<T> and ObservableCollection<T> do not support ranges dotnet/runtime#18087
• Support Bulk Operations in ListCollectionView via ObservableCollection<T> dotnet/wpf#1887
• https://github.com/dotnet/wpf/blob/main/src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Data/ListCollectionView.cs#L2520

To my knowledge, WPF does not support the Range parameter for NotifyCollectionChangedAction, which will throw a NotSupportedException. Therefore, for WPF, if I need to add or remove items in bulk, I can only use NotifyCollectionChangedAction.Reset to avoid exceptions. I'm curious how SourceCache handles this issue?

If I add 100 items, does SourceCache trigger 100 NotifyCollectionChangedAction.Add notifications? Or does it trigger a single Add or Reset?

[JakenVeina]

I've never myself had the opportunity to dig into the details of the various .Bind() operators, so take this with a grain of salt...

Any single operation performed on a SourceCache<> should (there's probably a few quirky exceptions I'm not aware of) generate a single keyed IChangeSet<> that's published to listeners. That really has nothing to do with WPF or any other UI framework, that's just all part of the DynamicData business layer.

The interesting part is what happens within a .Bind() operation. In the case of adding 100 items, like you say (assuming you perform those adds as a single operation at the source), .Bind() what happens is as follows:

• .Bind() invokes ObservableCollectionAdapter<>.Adapt() to apply the changeset to the target
• ObservableCollectionAdaptor<>.Adapt() sees that the number of non-refresh changes in the changeset (100) exceeds the default threshold of 25, and so decides to invoke ObservableCollectionExtended<T>.Load(), from its cached copy of the entire collection, instead of applying changes individually.
• ObservableCollectionExtended<T>.Load() performs a .Clear() and then a loop of 100 .Add()s to itself.
• ObservableCollection<T>.Clear() issues a NotifyCollectionChangedAction.Reset, and each of the .Add()s isses a NotifyCollectionChangedAction.Add`.

If you're looking to improve performance, what you'd want to do is implement your own version of DynamicData's IObservableCollection<T> and IExtendedList<T> interfaces, as those are what DynamicData looks for, to perform various range operations. However, like you say, WPF doesn't actually SUPPORT range operations, so the only one you'd really be able to optimize is .Load() to have it only publish a single NotifyCollectionChangedAction.Reset notification after all the changes have been performed, eliminating the need for all the NotifyCollectionChangedAction.Add notifications.

[glennawatson]

In ReactiveUI in our old ReactiveList's before we adapted over to using DynamicData, we used to have flags for WPF to only send through the non-range events. It's binding engine is very primitive.