Unifying `forEach` and `subscribe` return value - Subscriptions about proposal-observable

[zenparsing]

@benjamingr The problem that we mentioned in the other thread is that we don't want to mix error handling mechanisms. For instance:

let s = obs.subscribe({
  next(x) {},
  error(x) {},
});
s.catch(x => {});

This would confuse error handling.

I would like to introduce a counter-proposal:

• We eliminate Symbol.observer (synchronous subscription) and make subscribe synchronous, like Rx. The "subscribe" method has no zalgo-protection.
• forEach performs subscription asynchronously and has zalgo-protection and returns a normal promise. The error or return values are channelled through the promise.
• The argument to forEach accepts a value and a subscription object, which can be used to short-circuit.

// No zalgo-protection with subscribe
let subscription = observable.subscribe({ next, error, complete });

// forEach subscribes in a job, and flows errors and completion through the promise
observable.forEach((value, subscription) => {
  whatever;
}).then(
  returnValue => {}, 
  errorValue => {}
);

[benjamingr]

@zenparsing

@benjamingr The problem that we mentioned in the other thread is that we don't want to mix error handling mechanisms. For instance:

Why? Can't we just let catch for the observer run first and if no handler is attached or it threw let the promise handle it. In this proposal, the promise has no meaningful return value anyway so "value recovery" isn't a problem here.

[benjamingr]

That is: the catch on the promise only signifies that the observer terminated abruptly and that it didn't handle it in a catch, this has the benefit of aligning with async/await and throwing in the surrounding scope as well as benefiting from existing unhandled promise rejection tracking mechanisms

[benlesh]

I like @zenparsing's proposal better, and I agree, I think it's best to keep the subscription type simple. If we go to the extreme the other way, you could just about make a Subject out of the Subscription.

[benjamingr]

I see a ton of benefit to being able to await subscribe and not so many downsides. The channeling of error through the promise in forEach happens either way (since no error) - remember, making it a thenable is free in this case - no promise needs to be allocated per subscription unless you use it.

In both proposals you can make a subject out of the subscriber that's not really an issue with either.

I'm also +1 on forEach having zalgo protection but I'm still interested in seeing how subscribe can be made safer (that's another issue though). I'm also +1 on an additional subscription argument in every next callback, be it forEach or subscribe I really like that idea.

[benlesh]

I think it's semantically weird:

myObservable.subscribe(blah).then(doSomething);

Reads like: "Once you're subscribed, then do something". subscribe is usually the end of the chain.

[benjamingr]

Right, to be fair in 99.9% of cases most people would be using it as:

    await myObservable.subscribe({ next(v){
          doSomethingWith(v);
    /*...*/});

It's just useful to await subscribe in my opinion and I expect I'll use it in my code if it's available. It bothers me that if I forEach I can't access the callbacks using the observer interface - making any code that utilizes it (like specific instances of observer I create) impossible to use in this scenario. This is more painful if I implement a Subject in my code and I want to run the subject and await the subscription.

Given a then can be a getter and is free and it's useful, I'm not sure why we wouldn't want to have it for async/await support. It also means we can pass subscriptions to code using promises and it'll wait for the sequence to finish which is also useful.

[zenparsing]

@benjamingr Mixing async primatives at a basic level (i.e. subscribe) is going to be problematic. It can be done, but the clean way to do things is to keep them separated.

I am interested in a forEach-style alternate subscription function which only accepts a single callback and returns a promise for the return value or error. However, such a subscription function would essentially be an async task and until we have a story for cancellation of async tasks...

As I note at the end of the README, forEach is deferred for now.

To be honest, I'm actually more interested in allowing observables to be async-iterable:

async function af(observable) {
    for async (let x of observable) {
        // process observed values, throw if error, etc.
    }
}