Discussion: Add back an async subscription method?

[zenparsing]

Continuation of #38

From @jhusain

Reopening because as I'm putting together a summary of changes I'm somewhat confused by conclusion. It's clear we need sync subscription for EventTarget and for certain operators like GroupBy. It seems the original proposal of both an async and sync subscription option still works.

[benlesh]

It will be unfortunate if subscribe is async again. One of the issues I had with the two methods is then how should connect work on a ConnectableObservable (The result of a multicast)? I realize this proposal isn't RxJS, but a connectable observable or a "hot" observable seems like an inevitability. Would there need to be a connectSync and a connectAsync?

a subscribeOn is just a lot more flexible. FWIW, it seems like JavaScript should have native schedulers, because it's silly people keep reinventing microtask polyfills. That would be a whole different ball of wax, though.

[zenparsing]

I think async subscription is not intuitive for the general case. If I say "subscribe", I expect to receive any event which happens from the time "subscribe" returns onward. That's the crux of the EventTarget problem. In my opinion, this problem is general in scope: the issue will arise whenever we want to model events which are not buffered.

The goal of avoiding zalgo is good, though, and we should take it seriously.

Having two methods solves one problem, but it creates another: how is the non-expert developer supposed to know which is appropriate? The difference is too subtle, and I would rather this thing "just work" without having to explain such subtleties.

The ideal, for me, is a universe where subscription is always sync, but observables never deliver data before "subscribe" has completed. That's why I have Observable.of delivering its arguments in a job rather than synchronously.

Unfortunately, I was unable to come up with an API which would elegantly enforce such a limitation. In the end, I was content with core API not enforcing any such restriction, and instead relying on best-practices to emerge among users (with the help of the good example set by Observable.of).

Javascript is definitely missing an enqueueJob primitive though.

At the end of the day, the zalgo problem might not even matter that much. If observables are ultimately compatible with async iteration statements, then users can "subscribe" to an observable like this:

for await (let x of someObservable) {
    // Do whatever with `x`
}

Since control flow doesn't get split into sync and async paths, there is no zalgo to worry about.

[zenparsing]

Closing due to inactivity (and I'm still opposed to two subscription methods in the core proposal).