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

Support behaviour subjects in invoked observables #877

Closed
allforabit opened this issue Dec 14, 2019 · 6 comments
Closed

Support behaviour subjects in invoked observables #877

allforabit opened this issue Dec 14, 2019 · 6 comments

Comments

@allforabit
Copy link
Contributor

Bug or feature request?

Feature

Description:

It would be nice if invoked observables could respond to events that are sent to it. I noticed that this kind of behaviour was discussed in #435. I know the functionality is achievable by invoking a callback. I just find dealing with something like a behaviour subject a little more easy to work with as the callback api ends up being quite nested. I'm sure there may be good reasons why this wasn't implemented so please feel free to close if this is the case!

Below is the description of the behaviour that David described:

https://user-images.githubusercontent.com/12038627/56511892-0544d500-64eb-11e9-99d1-cdacc6bc0b81.png

@Andarist
Copy link
Member

Personally I would rather explore implementing smth similar to what I've described here. Adding more & more use cases into the core bloats the implementation and I think it would be better to offload this by exposing a single way of hooking any particular data source as service and having different adapters for different data sources.

@allforabit
Copy link
Contributor Author

Oh yeah that looks fantastic. An adapter based system would be much more flexible and would be a much better design. Is there an open issue for this? I think something like what you are suggesting would be a huge improvement. At the moment I'm using a slightly obscure library for streams (thi.ng/rstream) which is close but not exactly like an observable api. It would make things really straightforward if there was that single hook that I could write a simple adapter for. Is there an issue open for this or will I open one and close this one?

@davidkpiano
Copy link
Member

The real answer to this is having an Actor interface, which can be as simple as this:

interface Actor {
  send: (event: EventObject) => void;
}

Any API can be made to fit this interface (promises, observables, streams, near-observables, etc.) and this is also how most Actor libraries/frameworks/languages work.

So if you want a BehaviorSubject to work with this in the future, no adapters or built-in helpers or special libraries are needed. Just make it conform to that interface.

const subject$ = new BehaviorSubject();

// wrap the subject!
const createSubjectActor = subject => {
  return {
    send: event => subject.next(event)
  }
}

// ...

invoke: {
  src: () => createSubjectActor(subject$)
}

@Andarist
Copy link
Member

By adapters I meant smth like this - we would expose a single interface and other data sources would just implement/adapt it.

A simple interface like you have proposed would be great, big thumbs up from me. We’d only need to add a possibility to send events from invoked actor to the invoking one.

@allforabit
Copy link
Contributor Author

Yes I was just going to say that. This covers receiving events from the system but not, as @Andarist pointed out, sending events back into the system.

From what I can see, the first part (sending events to the spawned actor) already works in the current implementation by spawning an object with a send method. See codesandbox: https://codesandbox.io/s/brave-keller-exg5v I'm assuming this is where the new adapter / interface functionality will be implemented?

@davidkpiano
Copy link
Member

This (adapter) will be released in V5, and is currently in the next branch.

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