2-Way Binding to IObservable-like object from XAML

[fitdev]

One can easily bind to regular IObservable<T> from xaml by using ObservablePropertyName^ syntax.

However this is only good for one-way binding, i.e. where UI gets updated in response to observable's changes.

For 2-way binding it seems we always need INotifyPropertyChanged. However this seems to be somewhat inefficient for many scenarios - often there would be just one property on an object that could change, and dealing with string comparisons of property names at runtime seems wasteful. So, is there a way to have an IObservable<T> style binding that will work both ways, i.e. it will be able to convey back changes from the UI to the actual property type. Of course that type can't be just IObservable<T> since it will need to have a way to accept new values. So perhaps it can be something like Subject<T>, which is both an IObservable<T>, and IObserver<T>.

My understanding is that there is no such thing out of the box in Avalonia and there are no plans to support it, so that for XAML we would continue to rely on dated INotifyPropertyChanged approach. Can someone correct me if I am wrong?

Another question is - is it possible to implement such a functionality by creating a custom Binding-like Markup extension that will work with Avalonia XAML compiler? If so, can someone suggest a rough approach as how this can be done. At least in terms of creating custom markup extensions.

[maxkatz6]

Avalonia 11.1 still has InstancedBinding.TwoWay static method:

        public static InstancedBinding TwoWay(
            IObservable<object?> observable,
            IObserver<object?> observer,
            BindingPriority priority = BindingPriority.LocalValue)

which you should be able to use:

var instancedBinding = InstancedBinding.TwoWay(/* */);
BindingOperations.Apply(menuItem, MenuItem.IsCheckedProperty, instancedBinding);

Whole InstancedBinding is planned to be removed in 12, but we still have some time before that.

[maxkatz6]

Of course that type can't be just IObservable since it will need to have a way to accept new values. So perhaps it can be something like Subject, which is both an IObservable, and IObserver.

The problem is, Subject is not part of the BCL.
BCL only has IObservable and IObserver, but nothing combined.

[fitdev]

Thank you for the information and the tip on using InstanceBinding. However I certainly would not want to depend on something that is planned to be removed (incidentally - why?). But even if I wanted to, it is available from the code only.

1. I was thinking more along the lines of: <TextBlock Text="{MyNewBindingMarkupExtensionThatWorksWithASubject PropertyNameOfDataContextTypedAsSubject}" />, where basically, since it is not available in Avalonia out of the box I would base my won binding-like markup extensions that would understand Subject-like-typed values (whatever type I end up using for that).

The problem is, Subject is not part of the BCL.

That is unfortunate of course. But perhaps Avalonia could simply add their own interface/type to the core Avalonia library and use that. Maybe even have a separate Avalonia/UI-agnostic light-weight package which may include some other reactive stuff as well (some bits you have taken from Reactive Extensions instead of relying on that somewhat dated package directly).

3. Lastly, I wanted to better understand if my reasoning behind INotifyPropertyChanged is correct in that if XAML-based databinding was being designed today (i.e. from scratch), then there would be no place for an event-drived approach and instead Observables/Observers/Subjects would be used. Am I wrong with this assumption in that INotifyPropertyChanged is used for legacy/compat reasons but is otherwise not the most efficient solution compared with observables?

4. Off-Topic/Meta: I think it would be useful to have in the official docs or somewhere prominently in the repo (like maybe a pinned issue with links to other issues) a list of planned obsoletions/removals, so that people are aware and do not take needless dependencies, but instead try to "future-proof" themselves to as much a degree as possible.