Originally posted by benlesh January 21, 2022
Thinking about the backpressure-related use cases for interop between async iterables and observable, I think I'd consider it an improvement to ergonomics to implement Symbol.asyncIterator
on Observable
. See this comment here about handling backpressure. There are some really cool/easy/clever things that can be done with this functionality.
Here's a few things to consider:
concatMap
has exactly the same issue where users need to "understand there is buffering" in some cases, and so far, I haven't seen many people trip over that. In fact, many tutorials and documents steer people towards concatMap
for this buffered, one-at-a-time behavior more often than not.for await
isn't going away any time soon, and — other than callbacks — is the only real native way to iterate async values (one-at-a-time like concatMap
, of course).for await
is obviously non-cancellable, as there's no subscription or even an opportunity to pass a signal or the like, so it's unlikely to "replace" calling subscribe
in the hearts and minds of users.for await (const value of someObservable$) { await sleep(1000); const subValue = await getAnotherValue(value); doSomething(subValue); }
Which would roughly map 1-to-1 with this RxJS behavior:
someObservable$.pipe( concatMap(async (value) => { await sleep(1000); const subValue = await getAnotherValue(value); doSomething(subValue); }) ) .subscribe();
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4