Support callback/observable style API
See original GitHub issueAs per discussions on Discord, it’d be nice to have a callback/observable style API in meros
, for cases where using async iterators etc aren’t possible/desirable. Adding a ticket here to track that.
Issue Analytics
- State:
- Created a year ago
- Reactions:1
- Comments:9 (4 by maintainers)
Top Results From Across the Web
Intersection Observer API - MDN Web Docs
Be aware that your callback is executed on the main thread. It should operate as quickly as possible; if anything time-consuming needs to...
Read more >How to make Observable from callback - Stack Overflow
RxJS includes a bindNodeCallback observable creator specifically for creating observables from async functions that use Node-style callbacks ...
Read more >Observable | RxJS API Document - ReactiveX
Converts a Node.js-style callback API to a function that returns an Observable. It's just like bindCallback, but the callback is expected to be...
Read more >Bridging To Callbacks | RxJS - Javascript library for functional ...
Converting Callbacks to Observable Sequences. Many asynchronous methods in Node.js and the many JavaScript APIs are written in such a way that it...
Read more >Exploring RxJava - Wrapping a Listener Callback - Couchbase
A brief tutorial showing how to take a callback-based listener style API (think button clicks) to a reactive one using Observables with ...
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 FreeTop 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
Top GitHub Comments
Kind of a separate question - have you considered running non-multipart responses through the same API (just that it’d complete directly after a single part)?
That way one could always do
subscribe
etc in the observable case, and not worry about whether it is a multipart response or not. One could set up one flow that handles them both.I think that looks great! How would errors/completion be handled?
Re why: this particular project targets old(er) TVs, where async iterators aren’t supported, and where the code base itself has certain restrictions on the JS features it uses overall (even transpiled).
But outside of that, I think an observable/callback based API is more approachable in general, especially to some segments of developers. That’s obviously my highly personal opinion, you’ll of course need to decide whether you think those things are worth implementing and supporting that alternative API 😄