Optionally return an observable if no done method passed
See original GitHub issuefor example:
clubs.get({myArgs}, function(err,payload){
//do stuff
});
would still work but if no function is passed as the second argument an observable would be returned:
clubs.get({myArgs})
.flatMap(returnedClubList => Rx.Observable.return(returnedClubList ))
.flatMap(club => clubs.listMembers({getMembersFor: club}))
.subscribe(clubMember => console.log("club member: " + clubMember);
this would return a list of all club members from all clubs returned from the initial call.
Would you accept a pull request for this?
Issue Analytics
- State:
- Created 7 years ago
- Comments:8
Top Results From Across the Web
How to conditionally use return inside an observable in angular
The iff operator takes 3 arguments, first when being your condition, 2nd and 3rd being your different services that return an Observable.
Read more >How to keep an Observable alive after Error in Angular?
Let's take a look into these three methods:1.next() (Required):next method will be called by the Observable whenever a new value is emitted ...
Read more >Angular Basics: Introduction to Observables (RxJS)—Part 2
The observable function notifies the observer if an error occurs by calling the observer's error method and passing in the error information ...
Read more >Using observables to pass values - Angular
Observables are declarative —that is, you define a function for publishing values, but it is not executed until a consumer subscribes to it....
Read more >RxJS patterns - Conditionally executing work
If the result was false , we can return the never() Observable . This is an Observable that will have no events whatsover....
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I really like the idea, as this results in a much nicer API in my opinion.
Any reason you would use observables rather than promises? I would argue that promises are the better choice here, as they also seem to cover all use cases, do not introduce an additional dependency to ReactiveX and keep the libray’s API in line with the
fetch()
API etc:Observables won’t be implemented, but my Promise-based PR will be merged and released now that I’m maintainer. Closing this.