Selected item/Value woes

[glen-nicol]

I've been using DynamicData for a couple months now and think I am getting used to it. But one thing I keep having trouble with is Selection coherency.
The setup:
WPF
I bind a IObservable<IChangeSet<>> (with orwithout a key) to an ReadonlyObservableCollection via the Bind() function.
I bind a property to ListBox's SelectedValue property and set the SelectedValuePath.

Now when the selected item is replaced with an updated value it gets deselected. It seems DynamicData either does a remove+add when there is no key, and a replace when there is. But in both cases WPF deselects the item at least momentarily to replace it but that is enough for it to trigger my viewmodel with the selected property to get the null value and then proceeed to clearing out all sorts of things connected to that. And then the listBox reads back the null value that it changed to reevaluate the selectedItem.

So my question, is this a common problem for everyone with DynamicData? Is there a prescribed solution? Or is the answer "don't replace items and update the existing one instead"? Seems counter to the whole System.Reactive immutable methodology.

[JakenVeina]

Or is the answer "don't replace items and update the existing one instead"?

Yup.

Seems counter to the whole System.Reactive immutable methodology.

I don't know if I'd QUITE say that, but the sentiment is right: it can feel wrong to transition from a layer of immutable state to highly-mutable state. But that's a fallacy, there's nothing wrong about it.

The "immutable state store" pattern isn't the end goal, it's a means to an end. It works really well in your business layer and data layers, but it's a mistake to think that you should be extending it up to the View/ViewModel layers. WPF/UWP/all the XAML-based frameworks, they're simply not built that way. ViewModels work best when they are changed as infrequently as possible, and publish their own granular state changes, mainly because of how the binding system work. And at the end of the day, whatever mechanism you're using, your real end goal is to get your state changes merged into the Visual Element tree, which is very very much a mutable state structure. there's no getting around that.

You can still use immutable/reactive state in your core, and still reap all the advantages of that, when using mutable ViewModels. Even if your ViewModels have little islands of state that they manage, you can still set it up to all be derived from the central state store.

Also, avoid non-keyed collections within DynamicData like the plague. Unless you have a rare circumstance where it's impossible to derive an item key, the keyed collections and operators are going to run circles around the non-keyed equivalents, for performance.

Mechanically, here's a couple examples...

public record MyItemModel
{
    public required int Id { get; init; }
    public required string Name { get; init; }
    public required string Description { get; init; }
}

public class MyItemViewModel
    : INotifyPropertyChanged
{
    public required int Id { get; init; }
    public required string Name { get; set; }
    public required string Description { get; set; }
}

using var source = new SourceCache<MyItemModel, int>(static => item.Id);

using var binding = source
    .Connect()
    .Filter(...)
    .TransformWithInlineUpdate(
        transformFactory:   model => new MyItemViewModel()
        {
            Id          = model.Id,
            Name        = model.Name,
            Description = model.Description
        }, 
        updateAction:       (viewModel, model) =>
        {
            viewModel.Name          = model.Name;
            viewModel.Description   = model.Description;
        })
        transformOnRefresh: true)
    .Sort(...)
    .Bind(out var items)
    .Subscribe();

public record MyItemModel
{
    public required int Id { get; init; }
    public required string Name { get; init; }
    public required string Description { get; init; }
}

public class MyItemViewModel
    : INotifyPropertyChanged,
        IDisposable
{
    public MyItemViewModel(
        int                                 itemId,
        IObservableCache<MyItemModel, int>  source)
    {
        Id = itemId;
        
        var item = source
            .Watch(itemId)
            .Replay(1)
            .RefCount();
            
        item.Select(static item => item.Name)
            .DistinctUntilChanged()
            .Subscribe(name => Name = name)
            .DisposeWith(...);

        item.Select(static item => item.Description)
            .DistinctUntilChanged()
            .Subscribe(description => Description = description)
            .DisposeWith(...);
    }

    public required int Id { get; private init; }
    public required string Name { get; private set; }
    public required string Description { get; private set; }
}

using var source = new SourceCache<MyItemModel, int>(static => item.Id);

using var binding = source
    .Connect()
    .Filter(...)
    .DistinctValues(static item => item.Id)
    .Transform(itemId => new MyItemViewModel(
        itemId: itemId,
        source: source))
    .DisposeMany()
    .Sort(...)
    .Bind(out var items)
    .Subscribe();

Me personally, my preference is option 2. It makes it a lot easier, in my mind, to track the flow of changes.

[glen-nicol]

Solely that if the VM's need to be mutable to reuse it, then changing the collection also feels like a natural extension of mutating the VM.

To me what you've described many times in our conversations is a push towards mutable VM properties which are placeholders for the UI bindings and there is external control/ownership that is very flexible. I've come to see how that works pretty well with the library and understand it has performance wins too. However, for collections it feels flipped because the VM becomes the owner and everything is now internalized and must be replaced instead of reused. Its jarring and not cohesive.

What makes viewmodels with collections feel that was is that the Bind function more or less requires a constructor context otherwise the collection has to be replaced/rebound via property change notifications (another performance no no). In my mind, the owner of the readonlycollection is the Bind function not the calling class/function. I understand encapsulating the collection for the lifetime of the stream protects against a lot of misuse but that same protection means its cannot be repurposed.

I guess I would have expected the library to expose an overload of Bind that accepts an ObservableCollection<T> such that the caller can wrap that up in a readonly one if they want to protect it from external mutation but still maintain control of it. In my case the most needed control is just to clear it when the subscription ends so the items are not sitting in memory for the next use that will just blow them away. I did end up making such an overload myself in my own library.

Another reason for the library to expose an overload that accepted a reference to a Observablecollection<T> without the out keyword is a class could use a private member initialized with new() that is exposed via another property that is readonly. This would allow properties and functions to expose IObservable<> that don't require constructor contexts to bind to that member. This would also reduce the need to call Subscribe() all over the place(a big win for usage of RX from their design guidelines).

[JakenVeina]

However, for collections it feels flipped because the VM becomes the owner and everything is now internalized and must be replaced instead of reused. Its jarring and not cohesive.

Okay, I see what you're getting at. I don't really feel that way myself, but that makes sense. If flat values are just being pushed to a read/write property on a VM, it provides symmetry to have collection changes be pushed to read/write collections on a VM, and the VM can decide how and what to expose.

I guess I would have expected the library to expose an overload of Bind that accepts an ObservableCollection

Good news!

public static IObservable<IChangeSet<TObject, TKey>> Bind<TObject, TKey>(
        this    IObservable<IChangeSet<TObject, TKey>>  source,
                IObservableCollection<TObject>          destination,
                BindingOptions                          options)
    where TObject : notnull
    where TKey : notnull

IObservableCollection<T> is implemented by ObservableCollectionExtended<T> which extends ObservableCollection<T>.

[glen-nicol]

Jake comes to my rescue again! I'm a little embarrassed I didn't see that one.

[glen-nicol]

Hi Jake, was just troubleshooting a sorting issue with a keyed change set. It didn't sort properly. But applying a RemoveKey before it has solved the problem. I haven't updated to a version with BindAndSort(). Should I report that as an issue or just use the RemoveKey -> Sort -> Bind() and live with it until I upgrade?

Sorry for the never ending discussion topic. But we've covered so much ground it feels like this is cleaner than a whole new discussion to ask a small question.

[JakenVeina]

If you can demonstrate incorrect behavior with any existing operator, definitely report it. None of those operators are getting removed any time soon, even if we start recommending others, and when it comes to sorting, there's a lot of shared logic under the hood anyway.