What's the purpose of lift?

[voliva]

Yep, I know it's an internal detail, but I'd like to understand what is the purpose of it. I also posted a comment on #5431 asking this, but I think it fits more in discussions instead, as it's a general question.

When creating custom operators, a simple signature looks like

const myOperator = <T>(arg1: number) => (source: Observable<T>) => new Observable(
  subscriber => {
      return source.subscribe(/*...*/);
  }
)

However, all internal operators use source.lift() which also creates a `new Observable, and sets other internal properties to run the operator code when someone subscribes.

Now, from @benlesh 's post in #5431 I understand that lift was introduced to allow this scenario in v5:

class CustomObservable<T> extends Observable<T> {
  specialMethod(): void { }
}

const custom = new CustomObservable<T>;

custom.filter(fn).map(fn2).mergeMap(fn3).specialMethod()

However, if I transform this code to v6 or v7, that specialMethod is not there. Maybe types are wrong, but if I write it in just JS:

class CustomObservable extends Observable {
    specialMethod() { }
}
const custom = new CustomObservable();
console.log(
  map(x => x)(custom).specialMethod
);

This map is internally running custom.lift, and after running it this logs undefined. And if I call it, it throws an exception, as the method is just not there.

I started learning rxjs on v5, and the way we created custom functions and operators was by polluting the Observable's interface. Something like:

// Don't use this please
Observable.prototype.specialMethod = (): void => {}

So I never really used lift. But from the looks of it, even the internal use looks redundant and maybe it makes things a bit harder to follow?

Why are rxjs/operators using lift?

---

Edit: Obligatory meme

[cartant]

#60

[voliva]

Ah ty vm!, so I was only missing overriding the lift operator in CustomObservable:

class CustomObservable extends Observable {
  specialMethod() { }

  lift(operator) {
    const o = new CustomObservable();
    o.source = this;
    o.operator = operator;
    return o;
  }
}

with this, every operator seems to preserve specialMethod.

Is this kind of pattern generally used in the v6 ecosystem though? I've seen source and operator marked as deprecated (and with a big "Internal only, do not use") for a while now... does it make sense to keep it for v7?

[cartant]

... Is this kind of pattern generally used in the v6 ecosystem though?

I don't think so, but there are a lot of devs using RxJS, so there's bound to be a few. I know that early versions of AngularFire2 relied on it.

... does it make sense to keep it for v7?

The main reason for keeping it in v7 is that it wasn't deprecated in v6 - IIRC - so to remove it in v7 would give devs no notice.