Better subscription API

[jun-sheaf]

From internal usage, we notice there is a bit of confusion between using a subscribe function vs just a map. Could we investigate an alternative subscription API?

What worked for us

From our usage, we noticed that the removal of pipe has made using map and subscribe rather terse:

test$.map(console.log).subscribe()

With some additional custom operators, we can also deal with completion and error like so

test$
  .map(console.log)
  .catch(console.log)
  .complete(console.log)
  .subscribe()

The only thing that needs to be passed into subscribe is a signal.

For subjects, we have an additional operator designed specifically for subjects called "pipe" (yes, we repurposed the word) which takes a subject (the subject class, not an observer) and returns the source observable. (We haven't worked with this specific concept thoroughly though.)

[domfarolino]

What is the alternate API? catch() and finally() are both proposed operators, and subscribe() doesn't require any of its arguments, so I think what you're proposing is just a different (more verbose, given your second example) way of using the API that this spec proposes.

[jun-sheaf]

What is the alternate API? catch() and finally() are both proposed operators, and subscribe() doesn't require any of its arguments, so I think what you're proposing is just a different (more verbose, given your second example) way of using the API that this spec proposes.

The complete operator is not the same as finally.

Explicitly, I'm suggesting we shouldn't allow users to pass next, catch, or error into subscribe and rather enforce using operators.

Also, I'm not sure why you wrote the second example is more verbose. You use about the same (perhaps more) characters to do the same thing right now.

[domfarolino]

Also, I'm not sure why you wrote the second example is more verbose. You use about the same (perhaps more) characters to do the same thing right now.

It's four function calls instead of one, just to set up a single subscription!

Explicitly, I'm suggesting we shouldn't allow users to pass next, catch, or error into subscribe and rather enforce using operators.

IMO, the supplementary operators should be exactly that, supplementary, but not mandatory to set up the absolute basics and start processing values. I personally don't think there's a enough appetite to enforce using operators in this way. You are more than welcome to use them instead of the dictionary of callbacks as the way of handling Observable values, but I don't see the value in locking everyone into this method of usage.

[jun-sheaf]

It's four function calls instead of one, just to set up a single subscription!

Still doesn't mean it's verbose. Just means there are more runtime costs which are negligible for almost all applications.

Alternatively, we could investigate moving the signal into the observer instead of a separate parameter. Part of this issue is being required to pass an empty object for the first parameter when only cancellation may be needed.

[domfarolino]

Just means there are more runtime costs which are negligible for almost all applications.

This is a strange claim to make without evidence. Framework authors, who very well may use this API, and with whom we are in frequent contact, are always looking for absolutely every opportunity to avoid extra function calls or any allocations etc. I don't think this is a clear-cut case of it simply no mattering at all.

Alternatively, we could investigate moving the signal into the observer instead of a separate parameter.

In https://github.com/WICG/observable/issues/84 and https://github.com/WICG/observable/issues/71 it was decided that moving the signal out of the Observer was the best place for it actually. See discussion there for more details.