Open benlesh opened 9 years ago
I think because of an async-generator's inherent relationship with promises that async behavior is guaranteed (via A+) already. Fixing the implementations in RxJS or others should probably happen, to re-align with where the standards are, and their direction (composing async function*
=> observable
).
@calebboyd: I made that issue you referenced. :) and it's whole-heartedly related to my question here.
It seems to me that subscription should occur asynchronously by default, while event emission should occur synchronously, for performance reasons.
@blesh Yep, I agree. Would that imply a for(...on)
loop is an implicit subscription?
EDIT: talking about the block itself, not the inner loop code
Will
for...on
blocks (not the inner loop, specifically) be asynchronous, synchronous, or sometimes both?I ask this because I view
for...on
to be analogous to RxJS'sObservable.prototype.subscribe()
. And the behavior there is (IMO) confusing for developers, as it's sometimes synchronous, sometimes not.To be clear, I'm not asking about whether the emitted values are observed asynchronously, I'm asking about the act of subscription to the observable, specifically.
For example, in RxJS:
but given a different observable source, it behaves differently:
From the transpiled example in your README, I've surmized that the intent seems to be that subscription to an observable with
for...on
will be asynchronous, so that in all cases, the following should be true:If that is the case, should current Observable libraries strive to imitate this same behavior? Will async generators, in effect, be Observables? (i.e. carry the same interface as RxJS or Most.js like a
forEach
)? Should Observables themselves have some standardization similar to what A+ has done from Promises?