[Enhancement] Make Observables [IObservable<T>] a first-class-citizen in Maui

[ChaseFlorell]

Summary

in order to compete with other mobile frameworks that are already embracing reactive programming principles, I would love to see Maui move away from Events to IObservable. All of the plumbing required to do this is already in the System namespace and will not require any third party dependencies.

API Changes

• Deprecate or remove entirelyevents
• Implement IObservable<T>

Intended Use Case

Make .NET Maui more desirable to reactive programmers, and move away from traditional event subscriptions. This should help mitigate a large number of memory leaks that folks get into with their traditional event subscriptions, and also draw a new crowd of developers coming from platforms that have already adopted reactive programming.

NOTE:

This is not a discussion about RxUI, RactiveUI, Reactive.Marbles, etc.
This is purely around using System.Reactive and everything that already exists in the System namespace.

[GeraudFabien]

There is already ReactiveUi (License MIT) who intend to do that. If it's improvement that could be bring to help them i would agree.
But i don't thinks it's a good idea to do it natively since not everyone want or love Reactive programming.

[softlion]

ReactiveUI is very old and has a lot of very bad namings, behaviors, and architectural issues. Thus has very little adoption.

[ChaseFlorell]

ReactiveUI is very old and has a lot of very bad namings, behaviors, and architectural issues. Thus has very little adoption.

I'm not sure this is true. RxUI is undergoing a rewrite but I would argue there are minimal to zero architectural issues. I think the only reason it doesn't have higher adoption is because not enough folks know about it or how to use it. Once you start using observables, you'll wonder how you ever managed without them.

[ChaseFlorell]

There is already ReactiveUi (License MIT) who intend to do that. If it's improvement that could be bring to help them i would agree. But i don't thinks it's a good idea to do it natively since not everyone want or love Reactive programming.

RxUI is good, but I shouldn't need a third party library to leverage something that should already exist. Remember System.Reactive contains everything we need to implement observables in Maui.

[SkyeHoefling]

I like the idea of greater support for IObservable<T>. The 3rd party library ReactiveUI is great for getting reactive programming support into Xamarin.Forms today but it is ultimately a 3rd party library. Getting some level of support at the platform level will definitely make .NET MAUI a more competitive offering.

[GeraudFabien]

Explain yourself

The 3rd party library ReactiveUI is great for getting reactive programming support into Xamarin.Forms today but it is ultimately a 3rd party library. Getting some level of support at the platform level will definitely make .NET MAUI a more competitive offering.

What do you intend to solve/Improve ? Please help us understand you're need ?

The fact that ReactiveUI is a third party is not an problem at all.
FYI :

• Some MS employee support ReactiveUI and even made it...
• The first commit was made 15 jun, 2010. So it has 10 year.
• 1,489,946 download on nuget and 423 download a day currently

Has i said :

If it's improvement that could be bring to help them i would agree.

Currently you exposed no problem of ReactiveUI. Expose them and we can have a real discussion.

[softlion]

ReactiveUI is very old and has a lot of very bad namings, behaviors, and architectural issues. Thus has very little adoption.

[ChaseFlorell]

@GeraudFabien while all of your points are true, can you help me understand why I should have to use a third party library in order to gain access to things that already exist in the the System namespace?

[ChaseFlorell]

ReactiveUI is not a problem, in fact it's fantastic, however the purpose of this request is to make reactive programming a first-class citizen within System.Maui since System.Reactive has everything we need to make observable pipelines within Maui.

If we have to use RX UI, then we have to add a lot of additional boilerplate code in order to convert events into observables. Think Observable.FromEvent all over your code.

All of the non-microsoft cross-platform frameworks are using some form of reactive programming as a first-class citizen within their framework. Managing events in c sharp is a pain, and observables make that pain almost entirely disappear.

[sharwell]

I would certainly support a request to ensure that events work in the context of reactive-style application programming model (e.g. FromEvent is intended to support this, but may or may not be sufficient in its current form). However, I would discourage attempts to force a move to this style of application. Reactive APIs have a very steep learning curve, and I've observed cases in the past where attempting to adopt the approach resulted in order-of-magnitude increases in the amount of time it took to deliver an application with exactly the same functionality that normal event-based approaches would have offered.

I placed a 👎 vote on the proposal not because I think reactive is bad, but rather because the proposal explicitly moves in a direction that hurts developers not already using these approaches (i.e. it is a proposal for a change to help one group of users at the expense of another).

[softlion]

in a direction that hurts developers

This is because the ReactiveX library is too old, has lots of bad namings and caveats.
It's time to build a fresh one.

[ChaseFlorell]

@softlion bro you have to stop.

[softlion]

Stop what ? It's the truth. It hurts. Someone have to build another lib.
When you discover that Debounce is called Throttle in ReactiveX C#, you start asking yourself questions.
And there are quite a lots like that.

[ChaseFlorell]

I mean stop copy/pasting the same comment on others' posts.
Yes there are some language inconsistencies and I think Marbles aims to resolve many of those.

[ChaseFlorell]

FWIW: Throttle is the single reason I started using RxUI. If it hadn't been for Throttle, I'd probably still be stuck writing event driven UI as well. Oh the pain.

[pictos]

If you said to change event handlers to Action<T> and Func<T> I completely agree! But for change to IObservable<T> I don't agree, because I'm a dev that doesn't use it.

[softlion]

Because it's too hard to use. Always having to keep a variable to prevent it's dispose, and having to dispose it and at the correct time adds quite a complexity. But it's very powerful once you master it, that you won't come back to action.

Actions are kept in memory / disposed automagically (tx closures). If observables were too, it would be much easier.

[ChaseFlorell]

I understand that many devs don't use observables, mostly because they've never had a need to. Once you do however, you'll wonder how you ever did anything without them.

In my nearly 10 years of writing Xamarin apps, one thing has become painfully clear. Memory Leaks with events are everywhere in everyone's code. Event's aren't thread safe, they require explicit teardown, and the majority of developers fail to handle them correctly.

Observables are NOT a silver bullet, but they really help with most of these issues. Thread switching becomes a breeze, teardown with a composite disposable is easy, and with them you can manage multiple events/streams within a single pipeline.

[sharwell]

@ChaseFlorell It may soon be possible to use source generators to automatically generate IObservable<T> mirrors of events in a type.

[ChaseFlorell]

I did try using Pharmacist once, but I didn't have any luck.

[softlion]

Marble is already doing that correctly.

[softlion]

Pharmacist has been retired.

[ChaseFlorell]

yes I know about Marbles and the rewrite. I'm already running some of it in a new application.

[softlion]

ReactiveMarbles.PropertyChanged is working as expected. ReactiveMarbles.PropertyChanged.SourceGenerator too except on mono/vs mac which makes it useless for Xamarin yet (because of an issue with vs mac / mono or xamarin tooling which is unable to use msbuild 16+).

[SkyeHoefling]

@sharwell

@ChaseFlorell It may soon be possible to use source generators to automatically generate IObservable mirrors of events in a type.

I really like the idea of using Source Generators, that would reduce the maintenance burden and add support for IOBservable

[ChaseFlorell]

Maui is brand new, if folks still want to use events, perhaps we need a Legacy.Maui.Events source generator 😀

[RLittlesII]

MAUI is not brand new. It is old Xamarin in a new System namespace. Something something, same old stuff, something something new day.

[ChaseFlorell]

Oof, them's fighting words.

[RLittlesII]

I have refrained from commenting on this, as I know the stigma of a functional programmer is not something the .NET Eco System likes. It's been brought to my attention that I am just a "Functional Nut Job" who wants to cause problems for people by showing them a different way to approach application development.

Facts

• Reactive Programming has a steep learning curve
• Every other language has made the concept a first-class citizen (even PHP has made it first class)
• The original spec was developed by Microsoft Employees
• System.Reactive could use a bit of love
• Observables are easier to clean up than traditional .NET Event handlers
• Observables make multi-threaded applications easier to deal with
• The Observable API makes handling streams of events easier
• ReactiveX is a cross-platform spec and .NET, per usual, has taken the liberty of changing names to fit their concern (Debounce is Throttle, Serialize is Synchronize)
• There are no silver bullets

Truth

• Adding features that help one group does not immediately hurt another
• ReactiveUI is an MVVM offering that makes working with IObservable (which exists in the System namespace) easier to build applications with, it is not the only solution out there that supports this concept.
• C# devs don't even realize how functional the language has become. We love all the features but hate the term associated with them, Functional.
• Making IObservable a first-class citizen is probably the best way to get devs outside of .NET onto the platform.

What I want to see from MAUI are fewer Framework driven commands and more extensible events. Unfortunately, a lot of the newer Xamarin controls are taking the commanding approach, and making event-driven design a thing of yesteryear.

To say something is 10 years old and state that as a reason why we shouldn't use it seems a bit out of turn. By that reasoning we should just abandon .NET all together for something newer because newer is better?! I think this thread points out the exact reason why System.Reactive hasn't gotten much love in 10 years. .NET devs immediately hate any suggestion towards making a change to the way they write code. If Microsoft doesn't explicitly tell devs "This is the way" they will shy away from it, even though they don't have a history of the best recommendations.

So the concept of making IObservable a first-class citizen seems to threaten people's way of life. And I understand that. So maybe instead of "Replace" we should use softer language in this request. Even though I support the spirit of the original poster's thoughts.

[ChaseFlorell]

This is a net-new platform/framework. Why would it hurt anyone if the API surface is still being fleshed out and it's not ready for production?

[sharwell]

@ChaseFlorell I'm not trying to say the direction is bad or should be avoided altogether. I'm merely pointing out that one specific detail of the proposal is unnecessarily contentious, and restructuring the proposal to allow for multiple programming approaches may help gain momentum in adding support for the new functionality.

[RLittlesII]

@sharwell I was not singling you out.

[saint4eva]

C# has functional features since C# 1.0

[saint4eva]

@ChaseFlorell I'm not trying to say the direction is bad or should be avoided altogether. I'm merely pointing out that one specific detail of the proposal is unnecessarily contentious, and restructuring the proposal to allow for multiple programming approaches may help gain momentum in adding support for the new functionality.

You are right. And the whole point of dotnet Maui is to allow different app models : mvvm, MVU (e.g. Comet), Blazor app model and reactive. So, I do not know why they want to replace instead of extending the programming model.