Open Prunkles opened 3 years ago
AsyncRx is related to Rx the same way as AsyncSeq is related to Seq. They are all related to each other
Sync | Async | |
---|---|---|
Push | Rx | AsyncRx |
Pull | Seq | AsyncSeq |
So all these "collection" types are closely related to each other. In the same way Seq is also better supported than AsyncSeq. It would be nice to keep the impl and docs together but I have no clue of what the process is and who to contact.
I see they have an issue about that. But it's directly related to the .NET implementation, and I have no idea how it can natively transpiled to Fable (i.e. JS). Maybe we should take a look at the Fable plugin system?
Yes but the issue is about dotnet/reactive, the C# impl of AsyncRx made by Bart de Smet. This is quite a different implementation than my F# that uses Async instead of Task and tries to be lock free by using mailbox processors (to be Fable compatible)
Yes, I understand the problem. And I suggest to use the Fable plugin system to replace all FSharp.Control.Reactive functions with the corresponding FSharp.Control.AsyncRx functions. So a user can use FSharp.Control.Reactive library (which contains, for example, a Task-oriented code), but in fact the mailbox-based implementation will be used.
Actually all (supported) BCL types works exactly this way in Fable.
FSharp.Control.Reactive is a library that also implements Rx for F#. But it is oriented for the native (.NET, not Fable) runtime and actually is based on System.Reactive.
I like both libraries, but FSharp.Control.AsyncRx has Fable support, whereas FSharp.Control.Reactive has (to be honest) is better supported in general. I think that would be nice if they could somehow cooperate to get a solution that combines the benefits of both options. :slightly_smiling_face: