Alternative to Observables

[appden]

Hi, I fully admit I might be wrong or have missed something from reading this proposal, but please hear me out...

I'm quite convinced that having a async generator would very nicely complement async functions and generators within the language. However, I'm not convinced of the need for Observable or even the for-on syntax. If given an iterator that iterates over promises, consuming it is easy:

for (let promise of socket) {
    let price = await promise;
    ...
}

The harder part is actually creating that iterator that returns a promise for the next result. The code to properly accomplish that is quite convoluted, and could be vastly simplified with your proposed async generators. That is why I'd propose that an async generator actually return an iterator over promises for the next result.

This would greatly simplify this proposal, and I think give it a better shot of making it into ES7 as well as reduce the amount of new syntax and cognitive overhead for learners of the language. I agree with others' sentiment that for-on is too similar to in and of and a bit hard to spot in the code given its radically different behavior. I also agree that Observable would have some uses, but is better left to third-party libraries to implement and makes this proposal much heavier than it needs to be.

I also think returning an iterator would allow for very flexible patterns using iterator libraries with similar functionality to Python's itertools combined with await to accomplish amazing feats with very little code. 😄

[zenparsing]

Hi @appden

It's not quite that simple, because the done-ness of the sequence is itself asynchronous. You don't know whether to exit the loop until the promise is resolved.

See https://github.com/zenparsing/async-iteration#the-asynciterator-interface for more along those lines.

The main issue brought up against AsyncIterators is that they imply the overhead associated with promises and request queuing. Observables simply call their observer using a regular function call, so overhead is very low.

[appden]

Thanks @zenparsing, that makes a lot of sense. Still, I'm a fan of your AsyncIterator proposal.

[calvinmetcalf]

@zenparsing what is the relationship between your proposal and this one, is your version an alternate proposal?

[zenparsing]

@calvinmetcalf It's an alternate proposal that I developed a few months ago. Since then, I've come to think that observables are really great, but my personal opinion is that they should be implemented on top of async iterators. I don't speak for anyone other than myself though, and I'm not the feature champion.

[calvinmetcalf]

yeah observables have a lot of overlap with streams so seem a bit highlevel