Split platform specific schedulers into separate packages

[glopesdev]

After the great Rx reunification the four main assemblies (Rx-Core, Rx-Interfaces, Rx-Linq, Rx-PlatformServices) were merged into a single assembly and package for more consistent versioning.

While it is definitely reasonable to unify Core+Interfaces+Linq into one assembly, I feel the step to fold the PlatformServices assembly into the mix might be causing more issues than it solves. Below is a list of open issues which can all ultimately be traced back to this design decision:

• https://github.com/dotnet/reactive/issues/1059
• https://github.com/dotnet/reactive/issues/1476
• https://github.com/dotnet/reactive/issues/1628
• https://github.com/dotnet/reactive/issues/1651
• https://github.com/dotnet/reactive/issues/1745

Especially when considering the large number of platforms that Rx tries to target, I feel the platform-specific schedulers make everything more complicated both for consumers who just want to make their own libraries of platform-agnostic operators, and for app developers who may end up inadvertently with a more confusing dependency tree.

It also makes everything more confusing when the surface of an API significantly changes depending on which platform you target.

Going forward I propose that we separate out the platform-specific schedulers into independent packages for each UI framework (e.g. WinForms, WPF / UWP, etc) and have them be explicitly installed on a per-project basis rather than bundled in with System.Reactive depending on specific target frameworks.

[ScarletKuro]

Another related issue as well https://github.com/dotnet/reactive/issues/1461, in the comments I also tried to explain why it's bad and my proposal was following

Probably, would vote for separate package for each platform
System.Reactive.WPF -> DispatcherScheduler + extension methods.
System.Reactive.WinForm -> ControlScheduler + extension methods.
System.Reactive.UWP -> CoreDispatcherScheduler + extension methods.
System.Reactive.MAUI-> ...
etc

Current RX design impacts projects like Avalonia(they decided to remove System.Reactive because of it https://github.com/AvaloniaUI/Avalonia/pull/9749), MAUI, ReactiveUI etc. Definitely should be fixed.

Sorry for the tag, but the repository looks stale and this definitely requires some attention. @bartdesmet @clairernovotny

[Thaina]

Are there anything still move on this?

[ScarletKuro]

Are there anything still move on this?

No. The only movement I heard is that they are looking for new maintainers, but I'm not too sure about it. Maybe @HowardvanRooijen knows more.

[HowardvanRooijen]

There is movement, and we'll be providing an update this week.

[Thaina]

Thank you very much. I have high expectation on this

[HowardvanRooijen]

We've just published our high level plan: https://github.com/dotnet/reactive/discussions/1868

[idg10]

Just to loop back on this particular issue, the high-level roadmap we published in that PR commits to fixing this problem in Rx 7.0, but doesn't yet choose a specific solution.

Having researched the current situation and the options, I've come to more or less the same conclusion as the proposal in this issue.

I think a basic principle here should be that projects should only get UI-framework-specific Rx features if they ask for them. The current design in which it pulls in WPF and Windows Forms if your project has a Windows-specific TFM with an OS version of 10.0.19041 or higher is unhelpful because:

• people end up getting WPF and Windows Forms dependencies when they don't want them
• the means by which you do get these features when you do want them is kind of obscure
• the presence of UWP in the main System.Reactive component complicates lots of things

So I think we want to go with a design in which there will be a distinct component with Rx's WPF features, another with its Windows Forms features, another with its UWP features, etc. And looking beyond that, we think it should be possible for other frameworks (e.g. Avalonia) to define their own similar packages to provide Rx integration for their frameworks, should they want to do that. So we are considering putting these packages in entirely separate repos.

We do want to try to get community consensus on this design.

There are also some details to be worked out. We think that just reverting to the previous design won't necessarily work, because there was a slightly weird distribution of framework-specific features across multiple other components even before the great unification. So we think the unbundling of platform specific schedulers will probably involve the addition of new components.

We're also not sure yet what to do about backwards compatibility. The old pre-unification packages that currently have type forwarders into System.Reactive could be modified to type forward into the relevant new packages. But what do we do about code written today that depends on System.Reactive for UI-framework-specific features? I see two options:

1. introduce some brand new core Rx component, and turn System.Reactive itself into a facade component with type forwarders into the new components
2. remove the relevant types from System.Reactive (a breaking change) and hope we can provide enough docs to point people in the right direction for finding the new packages they need

Option 2 seems a lot cleaner, but it means breaking backwards compatibility.

[ScarletKuro]

We do want to try to get community consensus on this design.

I would personally tag some core members from ReactiveUI. They have a framework that supports many platforms, I'm sure they have opinion on that topic.

Maybe it's worth to involve Avalonia members too. I know they removed Rx, but maybe they would reconsider it if Rx will meet their requirements.

[Thaina]

So are there any progress about this issue as of yet?

The last release was 6.0 around 6 months ago

[HowardvanRooijen]

See https://github.com/dotnet/reactive/discussions/2038 For the latest discussion. A draft ADR with our current thinking should be published in the next week or so.