-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Comments
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. |
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? |
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$)
} |
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. |
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 |
This (adapter) will be released in V5, and is currently in the |
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
The text was updated successfully, but these errors were encountered: