asyncgenerator icon indicating copy to clipboard operation
asyncgenerator copied to clipboard

Question on for...on loop synchronicity

Open benlesh opened this issue 9 years ago • 3 comments

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's Observable.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:

let source = Observable.fromArray([1,2,3]);
console.log('start');
source.forEach(x => console.log(x));
console.log('end');

/*
start
1
2
3
end
*/

but given a different observable source, it behaves differently:

// some source the returns each thing asynchronously
let source = Observable.create(o => {
  setTimeout(() => {
    o.onNext(1);
  });
  setTimeout(() => {
    o.onNext(2);
  });
  setTimeout(() => {
    o.onNext(3);
  });
});
console.log('start');
source.forEach(x => console.log(x));
console.log('end');

/*
start
end
1
2
3
*/

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:

async function* nums() {
  yield 1;
  yield 2;
  yield 3;
}
let source = nums();
console.log('start');
for(var x on source) {
  console.log(x);
}
console.log('end');

/*
start
end
1
2
3
*/

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?

benlesh avatar Feb 22 '15 20:02 benlesh

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 avatar Feb 22 '15 21:02 calebboyd

@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.

benlesh avatar Feb 26 '15 02:02 benlesh

@blesh Yep, I agree. Would that imply a for(...on) loop is an implicit subscription?

calebboyd avatar Feb 26 '15 05:02 calebboyd