RFC: Ergonomic finalize?

[benlesh]

Problem

I frequently find code where users need to add a finalize() operator just to execute some finalization related code, when they don't even have any other operators to deal with. This adds complexity and boilerplate to something that should be simple.

source$.pipe(
  finalize(() => console.log('I was completed, errored, or unsubscribed'))
)
.subscribe(console.log);

Possible Solutions

Proposal 1: Add a finalize: () => void handler to the subscribe call.

This would mean that the following would work:

source$.subscribe({
  next: console.log,
  finalize: () => {
    console.log('I was completed, errored, or unsubscribed!')
  },
});

It should always fire after all teardown as occurred (and therefor after any complete or error calls). If we ever did add an unsubscribe handler (I'm against this), it would fire after that as well.

Gotcha: We CANNOT add this to Observer<T>

1. It's more of a lifecycle hook than something to be observed.
2. Subscriber and Subject implement Observer<T> as a means of sending notifications to a consumer. There's no reason to "forward" a "finalize" notification to a consumer. Finalize is an event that happens as a result of complete, error, or unsubscribe.

For prior art we have tap({ finalize: () => {} }) and of course finalize(() => {}).

Proposal 2: Add a finally() method to Subscription

For this, we'd add a new method to subscription that worked a lot like Promise#finally. Basically, adding a way to add a finalization callback in a familiar way.

const subscription = source$
  .subscribe(console.log)
  .finally(() => console.log('I was completed, errored, or unsubscribed'))

Con: This is basically add only it returns the Subscription

This really means we'd be adding two different ways to add a finalizer to a subscription. And add has been working fine. But then we're also in the same boat as promises where you can't "unfinally" your handler (nor can you "unthen" a standard promise). This makes for a duplicate, if a little deficient API for finalization.

Plus there are questions: Does it return the same Subscription instance? A new one? etc.

Proposal 3: Do nothing

Just what it sounds like. The finalize() operator has been working, even if it's a little cumbersome some times. Nothing new to worry about.

[LcsGa]

I personally wouldn't go for the second one because (even though I know rxjs isn't made for angular) I rarely subscribe to my observable directly. Thus it would be almost useless for me!
About the first one, I don't really see any issue with the fact that it's more like a lifecycle than an observer. For me an observer simply is an object that provide notifications that happens within a stream. A finalization could be a notification of that stream too in my opinion. About the subscriber and subject implementing observer, is it really an issue? Can't you simply omit the finalize method (I may have misunderstood the issue here though)