Windowscommunitytoolkit: Binding to Observables

[aL3891]

Hello!

I've been working on a small helper to enable binding to and from observables in xaml and also provide kind of an alternate way to implement INotifyPropertyChanged. I think it's pretty neat and I think it might be useful to the wider community, would it be something you'd be interested to have in the community toolkit?

Check it out at
https://github.com/aL3891/ObservableDatabinding

[hermitdave]

I would suggest you raise a User Voice for this.
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/category/193402-uwp-community-toolkit

Mixing Binding with Observable subscriptions is interesting though it could prove to be daunting to an average use who has never used Observables before.

[aL3891]

Created: https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/18766585-add-helper-for-binding-to-and-from-observables

Just to be clear, I've already written it, so i'm not asking anyone to do it for me :) I was just thinking it would be useful for others so I was wondering if you were interested in having it the toolkit and if so where it should go (and if you'd like to see other changes like naming and so on)

To provide some additional context, Binding to observables is a very common practice in for example angular2, infact that was how I started thinking about if and how it could be done for xaml as well. Back when rx was new I know people did use it for ui as well, but that was way back in the Silverlight days.

While I agree it can seem a little daunting, I also think its a very useful and powerful concept that can greatly simplify ui code as well as express dependencies between viewmodel properties in a nice way that is also separated from the view it self. It sounds a lot more difficult than it actually is, its basically just linq :)

[aL3891]

Any updates on this?

[skendrot]

Can you explain what is different from your implementation compared to ReactiveUI?

[aL3891]

I wasn't aware of ReactiveUI, but looking at it i can say for sure that my implementation is a lot smaller. it also does not require a special base class and no special property getter/setters. Instead each Property is its own observable with its own IPropertyChanged implementation.

From what i can gather my library has smaller scope, its not a mvvm framework, its just a set of wrapper classes for binding to and from observable values. Mine has a lot less "magic" (though not saying magic is a bad, but its not always what you want).

I think its a good fit for the toolkit because its so small, and yet enables alot of powerful scenarios and also is not particularly prescriptive in terms of the surrounding code so you can use it in existing apps without major code changes.

Did you check out the code/samples? i'll be happy to awnser if you have any questions.

[lucaasrojas]

Whats the current status of this issue?

[Kyaa-dost]

@aL3891 any update on this?

[aL3891]

i dont have any update, i made a proposal and awnsered @skendrot s questions but i never heard anything else back after that.. i still think this is a good proposal, but if the contributors are not interested, then i suppose that's it :)

[michael-hawker]

Hi @aL3891, I think there are a lot of other existing frameworks like MVVMLight or Fody that solve the underlying problems here you're trying to address.

I think just directing others to these existing solutions would be the best course for the toolkit, we've tried not to overlap too much with these MVVM libraries in the toolkit in the past.

Thanks for your interest in the Toolkit though, and please let us know if you have any other ideas or code to share in the future.

[aL3891]

Both of those are large (imo very large in the case of Fody) frameworks, what i was suggesting is basically a single class that would make implementing reactive ui alot easier regardless of framework.. i haven't looked at mvvm light in a while but i don't think either of them actually try to work with observables and as i wrote 3 years ago, this is not really a mvvm framework, its a way to bind to observables.

But it's clear you guys are not interested, it doesn't really seem like anyone ever even looked at this thing, so i think my time is better spent elsewhere to be honest :)

[michael-hawker]

But it's clear you guys are not interested, it doesn't really seem like anyone ever even looked at this thing, so i think my time is better spent elsewhere to be honest :)

Hi @aL3891, I'm sorry you feel this way, I had looked at your code sample and discussed it in relation to some of our other recent discussions on this topic, which then lead to the discussion here in #3230. The toolkit is a large project with many moving parts; we really rely on folks taking action to move things forward.

I'd love to hear your insights from having worked in this space on the active issue discussion thread called out above or take a look at the associated code in the draft PR #3229.

FYI @Kyaa-dost @Sergio0694

[Sergio0694]

Hey @aL3891 - please don't feel like we just ignored your issue and didn't even bother to check your code, that's not what happened! For instance, I went through your repo a few weeks back too.

Personally I'm afraid I don't really like the idea of that type though, for a number of reasons:

1. The type alone needs two separate NuGet packages just to make it work, specifically you're using System.Reactive.Core and System.Reactive.Linq. That's quite a bit of overhead for what should really be a minimal type. Besides, if you're going to reference 2 different packages you might as well just reference an actual MVVM package directly at that point.
2. From a usability perspective, this type makes it less intuitive to work with properties in a viewmodel. Every time you want to set a property you need to add .Value in your code, and similarly every binding path in XAML would also need to add the .Value property at the end.
3. From a performance perspective, I have a few issues with this type. It should be a simple INotifyPropertyChanged container for a property, but it results in quite a few objects being allocated every time (the container itself, plus 3-4 different objects stored in private fields), one being the closure class allocated to support the lamba expression used in the constructor, plus the overhead of the lambda invocation itself, and for the other APIs being used from those two imported NuGet packages.
4. I feel like this type would essentially "suggest" using what I basically consider to be an anti-pattern. An object can either be observable or not. If it is observable (eg. a viewmodel or an observable collection) you'd expect changes in its properties to send notifications. If it's not, you wouldn't. With this type instead users might start just adding properties of this type instead of properly implementing INotifyPropertyChanged, and would end up with "hybrid" types that themselves don't support notifications, while having some properties that do. I don't think this is really how the MVVM pattern is supposed to be used.
5. It'd also break away from the usual MVVM structure (properties with notification), introducing a specialized type that's not seen anywhere else, making it more difficult for more users to go through code, or reuse the same feature elsewhere. Literally every existing MVVM framework I've seen strictly relies on the INotifyPropertyChanged interface being implemented in a base class of some sort, with properties just being of their "expected" type instead.
6. You claimed that without this type it's difficult to express "dependencies between properties", but I'd argue that's not really true. All you need to do in that case is simply to raise the notification from dependent properties when one property changes (ie. from its setter).

That said, the core idea of this type could easily be implemented through the new ObservableObject type present in #3229 if we wanted, by writing the following:

public sealed class ObservableElement<T> : ObservableObject
{
    private T value;

    public T Value
    {
        get => this.value;
        set => Set(ref this.value, value);
    }
}

I just don't think this type itself is a good idea to have in general though, for the reasons above. If users want to have an object that can send notifications from properties, they should just inherit from ObservableObject and simply use the provided Set<T>(ref T, T, string) method to update the property and send notifications if needed.

Of course, these are just my 2 cents on the issue and the code I've seen 😊

[Kyaa-dost]

I couldn't agree more with @Sergio0694. As you know we receive volumes of requests in this repo on a daily basis and yet we still make certain every issue receives priority to be resolved. We have looked into this issue multiple times with different resolutions in the meetings but what @Sergio0694 highlighted above is really significant to understand.

Also, if anything you would like to mention please feel free to provide feedback as we are always improving the life cycle of issues.

[aL3891]

@michael-hawker

we really rely on folks taking action to move things forward.

I really do feel that I did everything address the comments in the initial posts, but I suppose I could have been more persistent. I'd caution though that many people coming in to oss projects will be weary of repeatedly pinging repo owners for feedback, so you may not be able to rely on that for new contributors at least.

@Sergio0694
Fair points. I would argue though that i have not pitched this as a mvvm framework or replacement, i even mentioned back in the initial discussion that this is something much smaller than a mvvm framework.

My impression, certainly at the time of making this issue, was also that the wct wasn't strictly a mvvm focused library but rather a collection of utilities to make writing xaml apps easier in general, of course that might have changed over time. Even so, part of the reason I wanted to make something like this is exactly that no major mvvm frameworks or other ui libraries supported observables witch I think is a shame since they are very useful

I do disagree with your point 6 though, listening to and composing INotifyPropertyChanged events seems like a huge mess compared to composing IObservables.. For example having an Events property and other properties based on that for Warnings and Errors. For those simple cases it's not too bad, but once you get into windowing functions INotifyPropertyChanged listeners get pretty complicated.

Your ObservableElement class is missing the streaming/composability aspect that IObservable/IAE provides witch i'd argue is the main point of my suggestion. It'll raise events, but not allow property composition (as in linq style composability)

I don't see this as being all that different from DependencyProperties (witch of course are also considered an anti pattern by some) in that they are a type that encapsulates the "dependency" part of the property but (in my view) in a much less invasive way

Also, remember that i wrote this in 2017, in the .net core 1.1 timeframe.. A lot has happened since then including IAsyncEnumerable as well as ObservableObject. I'm not that surprised that you have objections against things like dependencies now, and I'm pretty sure I could rewrite it to not have any dependencies now using things like channels and IAE witch are also much more performant. But yeah, since you're not into the idea in general.. :)

I just wish you'd responded to this issue a bit sooner, especially if you discussed it in meetings or other forums..

@Kyaa-dost

As you know we receive volumes of requests in this repo on a daily basis and yet we still make certain every issue receives priority to be resolved

I think this issue (again, from 2017) is evidence that this ambition might not be fulfilled just yet.. :) Of course, that's a bit unfair alot has happened since then, i'm sure it's better now a days, but i hope you understand why i'm a bit salty. I feel like I did everything I could to address feedback when this issue was created but i didn't get a lot of response.

please feel free to provide feedback as we are always improving the life cycle of issues.

If you receive more requests to contribute than you can handle that's great, not a lot of projects manage to generate that level of engagement. In my experience, getting people to spend their free time working on someone else's project is a challenge and i'd advice you to be careful to not take your contributors for granted.

[michael-hawker]

@aL3891 really appreciate all your feedback. The toolkit is constantly evolving and has gone through numerous transitions since this issue was originally raised. I did want to comment on this:

we really rely on folks taking action to move things forward.

Part of what I meant by this too is not just about someone pinging repo owners asking if a feature should be included, but about multiple folks in the community coming together to rally an issue and a contribution. That's what has been happening recently with #3229 that revived this discussion and the debate around MVVM in the toolkit.

We do certainly get a lot of requests, but there are only a relative few working on the toolkit. We really do honor and rely on the contributions from the community to champion issues and features, have discussions around APIs and impacts, and also open PRs with their ideas to collaborate and move forward on together.