Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fable support #159

Open
Prunkles opened this issue Feb 17, 2021 · 3 comments
Open

Fable support #159

Prunkles opened this issue Feb 17, 2021 · 3 comments

Comments

@Prunkles
Copy link

Prunkles commented Feb 17, 2021

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.

@deviousasti
Copy link
Member

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.

@Prunkles
Copy link
Author

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)

@panesofglass
Copy link
Collaborator

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants