-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stop composing custom observable instances in version 8 #5431
Comments
Core Team Meeting Notes: Do it. |
Yeah, recently I was managed to map |
- Removes `_isScalar` as it was unused - makes `lift` `protected`. This is an internal implementation detail. - makes `source` `protected`, this is an internal implementation detail. - Refactors operators to use new utility functions that do the lift or provide a reasonable error if the observable someone is trying to use with the operator does not have a lift method. Adds documentation. BREAKING CHANGE: `lift` no longer exposed. It was _NEVER_ documented that end users of the library should be creating operators using `lift`. Lift has a [variety of issues](ReactiveX#5431) and was always an internal implementation detail of rxjs that might have been used by a few power users in the early days when it had the most value. The value of `lift`, originally, was that subclassed `Observable`s would compose through all operators that implemented lift. The reality is that feature is not widely known, used, or supported, and it was never documented as it was very experimental when it was first added. Until the end of v7, `lift` will remain on Observable. Standard JavaScript users will notice no difference. However, TypeScript users might see complaints about `lift` not being a member of observable. To workaround this issue there are two things you can do: 1. Rewrite your operators as [outlined in the documentation](https://rxjs.dev/guide/operators), such that they return `new Observable`. or 2. cast your observable as `any` and access `lift` that way. Method 1 is recommended if you do not want things to break when we move to version 8.
- Removes `_isScalar` as it was unused - makes `lift` `protected`. This is an internal implementation detail. - makes `source` `protected`, this is an internal implementation detail. - Refactors operators to use new utility functions that do the lift or provide a reasonable error if the observable someone is trying to use with the operator does not have a lift method. Adds documentation. BREAKING CHANGE: `lift` no longer exposed. It was _NEVER_ documented that end users of the library should be creating operators using `lift`. Lift has a [variety of issues](#5431) and was always an internal implementation detail of rxjs that might have been used by a few power users in the early days when it had the most value. The value of `lift`, originally, was that subclassed `Observable`s would compose through all operators that implemented lift. The reality is that feature is not widely known, used, or supported, and it was never documented as it was very experimental when it was first added. Until the end of v7, `lift` will remain on Observable. Standard JavaScript users will notice no difference. However, TypeScript users might see complaints about `lift` not being a member of observable. To workaround this issue there are two things you can do: 1. Rewrite your operators as [outlined in the documentation](https://rxjs.dev/guide/operators), such that they return `new Observable`. or 2. cast your observable as `any` and access `lift` that way. Method 1 is recommended if you do not want things to break when we move to version 8.
I've been probably late on the From OP it looks like it was added to keep methods from the prototype chain when applying operators, but as of now, this code (using just JS): class CustomObservable extends Observable {
specialMethod() { }
}
const custom = new CustomObservable();
console.log(
map(x => x)(custom).specialMethod
); logs undefined, which means that even though Edit: Asked in #6148 |
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: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 breaksconnect
. Try this:This doesn't work:
And this doesn't work:
This the byproduct of a few things, but chief among them are:
publish()
et al, should not be "pipeable operators".lift
was a cool experiment, but ultimately was of limited value and required some strange workarounds in all cases.lift
on a subclass ofObservable
requires the developer to have knowledge ofObservable
's implementation details. (You have to setsubclass.operator
andsubclass.source
etc).For version 8, I'd like to eliminate the composition of types like
ConnectableObservable
,Subject
and "custom observables" through operators as a goal.The text was updated successfully, but these errors were encountered: