Deprecating MapTo variants.

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:

Closures are much faster.
Therefor the whole library is written in such a way that is uses closures.

Considering that mergeMapTo(x) and mergeMap(() => x) do pretty much the same thing, only one is hiding the closure, I thikn we should deprecate the MapTo variants to help clean up the core API.

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.

@kwonoj

Core Team meeting:

👍 to deprecate
❓ Maybe not remove until version 9 (@kwonoj)

@backbone87

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 mapTo is kinda useful :)

update dependencies and code

chore: deprecate MapTo variants

chore: revert `switchMapTo`s back to `switchMap`

chore: do not use `mapTo`s variants

chore: deprecate MapTo variants (ReactiveX#6860)

Navigation Menu

Repository navigation

Deprecating `MapTo` variants. #6399

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Deprecating MapTo variants. #6399

Description

Activity

backbone87 commented on May 12, 2021

benlesh commented on May 19, 2021

sod commented on Jul 2, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Deprecating `MapTo` variants. #6399