Description
We are currently jumping through a lot of hoops in order to preserve the type through the operator chain, when that is no longer as relevant. As a hold-over from the dot-chained days, there was an attempt, starting in v5, to maintain the same type through operators by leveraging lift
. This was done such that this would still work:
class CustomObservable<T> extends Observable<T> {
specialMethod(): void { }
}
const custom = new CustomObservable<T>;
custom.filter(fn).map(fn2).mergeMap(fn3).specialMethod()
Over the years this has proven to have limited value, and in fact, is flawed in some ways. For example, look at the code we've had for years in order to support "lifting" publish operators in such a way that connect
composes through.
Fact is, the current implementation doesn't support what it claims, because if you have more than one publish
operator in the chain, it breaks connect
. Try this:
This doesn't work:
interval(100).pipe(
publish(),
publish(),
refCount()
).subscribe(x => console.log(x));
And this doesn't work:
const source = interval(100).pipe(publish(), publish());
source.subscribe(x => console.log(x));
source.connect();
This the byproduct of a few things, but chief among them are:
publish()
et al, should not be "pipeable operators".- Composing custom types (or even Subject) through the operators via
lift
was a cool experiment, but ultimately was of limited value and required some strange workarounds in all cases. - Implementing
lift
on a subclass ofObservable
requires the developer to have knowledge ofObservable
's implementation details. (You have to setsubclass.operator
andsubclass.source
etc).
Activity