RFC: When to remove `Observable#lift`?

[benlesh]

This is an issue to track to the deprecation and removal of lift in v9.

lift was a really interesting idea and a revolutionary thing we added back in v5. The initial promises it held were around performance, the idea that you could add custom "methods" to an inherited custom Observable and keep them after calling a native method, and that enabled things like Subject to still be a Subject after you operated on it.

Why we'd want to remove it

1. It means we're implementing our operators the same way we'd recommend other people implement their operators.
2. It means that we're compatible with any "same shaped" observable implementation more directly. )See test in associated PR here: 6403d8a#diff-c8b60d7f1c5a1e59f4a311cdc025d29918fef109c66428feaa6a7aa193803928R283-R305)
3. It reduces code size and code complexity.
4. It preps us for a future where a standalone RxJS Observable doesn't have anything "RxJS-specific" on it, (except maybe Observable#pipe, which is just generally useful).
5. We stopped using "methods" for operators years ago, and we've long recommended against people inheriting from Observable. In fact, it's an industry standard that subclassing types you don't own is a bad practice unless it's documented API (React.Component, or something like that). So lift doesn't have the same purpose it used to.

Remove in v8 or v9?

So there's some debate to be had here with the Core Team:

While we've already had lift deprecated for a very long time. We're making it internal in v8 (per the comments in the codebase). And the "lifted observable" behavior is still supported, even if it's not supported by TypeScript.

Should we completely remove lift in v8? We can get away with this since it's been slated to be made internal (meaning it's not a public API in version 8). In other words, if it's not a public API, no one should have any expectations of behaviors associated with it beyond things that RxJS itself does.

The only issue I see is currently RxJS supports the composition of our subject variants through the operator chain, via lift. This is a little known aspect of RxJS that isn't used much, in no smart part because TypeScript can't support it:

const subject = new Subject<number>()

const lifted = subject.pipe(map(n => n + '?'), map(s => s + '!');

lifted.subscribe(console.log);

(lifted as any).next(42); // logs "42?!"

The workaround if we remove lift entirely is the obvious and correct thing:

const subject = new Subject<number>()

const lifted = subject.pipe(map(n => n + '?'), map(s => s + '!');

lifted.subscribe(console.log);

subject.next(42); // logs "42?!"

I say it's more "correct" because really it's probably not great to pass your data producer around as part of your consumer API. (We even provide asObservable() to cover that)

[dariomannu]

I say it's more "correct" because really it's probably not great to pass your data producer around as part of your consumer API. (We even provide asObservable() to cover that)

@benlesh, I know I'm a bit late to the party on this, but I feel like this trades a bit more ergonomics for a bit less security (see below), even where the latter might not be required.

1. We know it's annoying for some people to create a whole stream first and then separate a consumer out through asObservable:

const stream = new Subject().pipe(stuff);
const consumer = stream.asObservable();
expose(consumer);

2. However, it's also annoying to create a separate subject from its pipeline when we do want to expose the producer:

const producer = new Subject();
const consumer = producer.pipe(stuff);
expose(producer);

Please note: by exposing producer in the latter example, someone may also expose an unintended consumer of the producer: bad guys might still do producer.subscribe(...) and skip the pipeline, since there's no Subject.asObserver available.

How about leaving Subject and BehaviorSubject as they used to be (so we don't break existing code that hard) and create some separate lift-free constructs (PureSubject, SecureSubject, ObservableSubject, whatever the name), to accomodate both use cases?