Open Prunkles opened 3 years ago
Hi,
This library wraps System.Reactive
into an idiomatic F# API. The Rx concurrency model, and more importantly Rx semantics are expected from the operators which are non-trivial to write correctly.
A better approach would be a Fable wrapper over rx-js
which tries to implement the Rx behavior correctly.
Yes, I absolutely agree with you!
But when AsyncRx.NET is implemented in this library (according to this issue), then there will be interfaces (like IAsyncObservable
, IAsyncDisposable
) and there is a risk that they will only be in this library, and it will be impossible to share them between different libraries (e.g. FSharp.Control.Reactive for a backend, FSharp.Control.AsyncRx for a frontend, and nothing to link them together)
@Prunkles I agree with the sentiment that it would be nice to have one library like this that provides these behaviors. However, as @deviousasti notes, I'm not sure how we would do this. My best guess is that we would need to essentially have two code paths for everything in here, one to wrap dotnet/reactive, and another for rx-js (and possibly yet another to bridge to FSharp.Control.AsyncRx). The number of inconsistencies and effort to maintain it seems like it would be really challenging.
I think the best bet would be to port the features here to FSharp.Control.AsyncRx as it should be able to run on both the front- and back-ends. I suspect it suffers from some performance degradation from dotnet/reactive, at least based on previous efforts to do the same sort of thing.
Description
Since this library is based on dotnet/reactive which is implemented using Tasks, it cannot be used with Fable.
Known workarounds
There actually is a library that implements ReactiveX for F# Fable using mailboxes — FSharp.Control.AsyncRx. I think it would be nice to merge these libraries into one.
By the way, I already mentioned this in the issue.