-
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
Deprecating MapTo
variants.
#6399
Comments
some usages experience a decrease in ergonomy: mapTo(new Foo());
// vs
const foo = new Foo();
map(() => foo);
// vs
map(((foo) => () => foo)(new Foo())); personally, I have used this behavior on a few occasions. this isn't a big deal, just wanted to make sure this case is considered. |
Core Team meeting: 👍 to deprecate |
This is genius. The documentation becomes easier to digest for newcomers and operators are easier to discover. And push developers into writing their first operator themself to harness the full potential of rxjs, as @backbone87 already mentioned, having a |
This is the usual dependency update before a release (scheduled to be the v3.26.2). After updating `typescript-eslint`, new linter errors made their apparitions, for cases where an `any` type is used as a function argument (the rule in question is [no-unsafe-argument](https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/docs/rules/no-unsafe-argument.md)). That's a rule we want (`any` is ___bad___ after all!) but RxJS, our main dependency, does not respect it well. Especially, some operators which transform an observable into another without needing to look at the items of the source Observable (e.g. `mapTo`, `mergeMapTo`, `switchMapTo`, `ignoreElements`) have an `any` in their type definition for the type of the source Observable's elements (where an `unknown` would actually suffice and be type-safe). Replacing on their side this `any` by `unknown` is planned for their 8.x.x release (which is not yet released). In the meantime, we had to find a solution. I chose to do two things: 1. Replace all the "***To" (`mapTo`, `mergeMapTo` and so on) operators by their callback-based equivalent (`map`, `mergeMap` and so on). I did that mostly because RxJS devs [seems to plan deprecating the ***To operators anyway in profit of the callback-based ones](ReactiveX/rxjs#6399). 2. For the last remaining operator, `ignoreElements()`, I just disabled the rule with a long comment attached on top of each case.
This is the usual dependency update before a release (scheduled to be the v3.26.2). After updating `typescript-eslint`, new linter errors made their apparitions, for cases where an `any` type is used as a function argument (the rule in question is [no-unsafe-argument](https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/docs/rules/no-unsafe-argument.md)). That's a rule we want (`any` is ___bad___ after all!) but RxJS, our main dependency, does not respect it well. Especially, some operators which transform an observable into another without needing to look at the items of the source Observable (e.g. `mapTo`, `mergeMapTo`, `switchMapTo`, `ignoreElements`) have an `any` in their type definition for the type of the source Observable's elements (where an `unknown` would actually suffice and be type-safe). Replacing on their side this `any` by `unknown` is planned for their 8.x.x release (which is not yet released). In the meantime, we had to find a solution. I chose to do two things: 1. Replace all the "***To" (`mapTo`, `mergeMapTo` and so on) operators by their callback-based equivalent (`map`, `mergeMap` and so on). I did that mostly because RxJS devs [seems to plan deprecating the ***To operators anyway in profit of the callback-based ones](ReactiveX/rxjs#6399). 2. For the last remaining operator, `ignoreElements()`, I just disabled the rule with a long comment attached on top of each case.
This is the usual dependency update before a release (scheduled to be the v3.26.2). After updating `typescript-eslint`, new linter errors made their apparitions, for cases where an `any` type is used as a function argument (the rule in question is [no-unsafe-argument](https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/docs/rules/no-unsafe-argument.md)). That's a rule we want (`any` is ___bad___ after all!) but RxJS, our main dependency, does not respect it well. Especially, some operators which transform an observable into another without needing to look at the items of the source Observable (e.g. `mapTo`, `mergeMapTo`, `switchMapTo`, `ignoreElements`) have an `any` in their type definition for the type of the source Observable's elements (where an `unknown` would actually suffice and be type-safe). Replacing on their side this `any` by `unknown` is planned for their 8.x.x release (which is not yet released). In the meantime, we had to find a solution. I chose to do two things: 1. Replace all the "***To" (`mapTo`, `mergeMapTo` and so on) operators by their callback-based equivalent (`map`, `mergeMap` and so on). I did that mostly because RxJS devs [seems to plan deprecating the ***To operators anyway in profit of the callback-based ones](ReactiveX/rxjs#6399). 2. For the last remaining operator, `ignoreElements()`, I just disabled the rule with a long comment attached on top of each case.
This is the usual dependency update before a release (scheduled to be the v3.26.2). After updating `typescript-eslint`, new linter errors made their apparitions, for cases where an `any` type is used as a function argument (the rule in question is [no-unsafe-argument](https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/docs/rules/no-unsafe-argument.md)). That's a rule we want (`any` is ___bad___ after all!) but RxJS, our main dependency, does not respect it well. Especially, some operators which transform an observable into another without needing to look at the items of the source Observable (e.g. `mapTo`, `mergeMapTo`, `switchMapTo`, `ignoreElements`) have an `any` in their type definition for the type of the source Observable's elements (where an `unknown` would actually suffice and be type-safe). Replacing on their side this `any` by `unknown` is planned for their 8.x.x release (which is not yet released). In the meantime, we had to find a solution. I chose to do two things: 1. Replace all the "***To" (`mapTo`, `mergeMapTo` and so on) operators by their callback-based equivalent (`map`, `mergeMap` and so on). I did that mostly because RxJS devs [seems to plan deprecating the ***To operators anyway in profit of the callback-based ones](ReactiveX/rxjs#6399). 2. For the last remaining operator, `ignoreElements()`, I just disabled the rule with a long comment attached on top of each case.
Deprecating MapTo variants, as they were only wrappers around the Map variants, and added unnecessary API surface area. related ReactiveX#6367 resolves ReactiveX#6399
this change looks forward to rxjs v8 for more info see ReactiveX/rxjs#6399
this change looks forward to rxjs v8 for more info see ReactiveX/rxjs#6399
Based off of a comment here
At one point, there was some performance advantage to having
mapTo
,concatMapTo
,switchMapTo
, et al. Because they introduced a way to map to the same value over and over again, without introducing a closure.Now:
Considering that
mergeMapTo(x)
andmergeMap(() => x)
do pretty much the same thing, only one is hiding the closure, I thikn we should deprecate theMapTo
variants to help clean up the core API.The text was updated successfully, but these errors were encountered: