RxJs: ConcatMap VS ConcatMapTo, MergeMap VS MergeMapTo
up vote
1
down vote
favorite
The documentation isn't helpful enough for me to understand the difference between these.
It's like concatMap, but maps each value always to the same inner
Observable.
http://reactivex.io/rxjs/file/es6/operators/concatMapTo.js.html
I tried checking out learnrxjs.io's examples on stackblitz, but even with those, I wasn't able to immediately identify what the distinguishing feature was separating these.
FYI i saw this other similar question
What is the difference between mergeMap and mergeMapTo?
but the answer in there wasn't satisfactory, because in the learnrxjs.io examples, they clearly map to observables, not hard-coded values.
https://www.learnrxjs.io/operators/transformation/concatmapto.html
If someone could provide some examples (and maybe a brief explanation) to help distinguish the *** vs the ***To higher-order observable operators, I'd appreciate that, thanks.
rxjs rxjs6
asked Nov 10 at 14:48
squirrelsareduck
3811312
add a comment |
up vote
1
down vote
favorite
The documentation isn't helpful enough for me to understand the difference between these.
It's like concatMap, but maps each value always to the same inner
Observable.
http://reactivex.io/rxjs/file/es6/operators/concatMapTo.js.html
I tried checking out learnrxjs.io's examples on stackblitz, but even with those, I wasn't able to immediately identify what the distinguishing feature was separating these.
FYI i saw this other similar question
What is the difference between mergeMap and mergeMapTo?
but the answer in there wasn't satisfactory, because in the learnrxjs.io examples, they clearly map to observables, not hard-coded values.
https://www.learnrxjs.io/operators/transformation/concatmapto.html
If someone could provide some examples (and maybe a brief explanation) to help distinguish the *** vs the ***To higher-order observable operators, I'd appreciate that, thanks.
rxjs rxjs6
asked Nov 10 at 14:48
squirrelsareduck
3811312
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
The documentation isn't helpful enough for me to understand the difference between these.
It's like concatMap, but maps each value always to the same inner
Observable.
http://reactivex.io/rxjs/file/es6/operators/concatMapTo.js.html
I tried checking out learnrxjs.io's examples on stackblitz, but even with those, I wasn't able to immediately identify what the distinguishing feature was separating these.
FYI i saw this other similar question
What is the difference between mergeMap and mergeMapTo?
but the answer in there wasn't satisfactory, because in the learnrxjs.io examples, they clearly map to observables, not hard-coded values.
https://www.learnrxjs.io/operators/transformation/concatmapto.html
If someone could provide some examples (and maybe a brief explanation) to help distinguish the *** vs the ***To higher-order observable operators, I'd appreciate that, thanks.
rxjs rxjs6
asked Nov 10 at 14:48
squirrelsareduck
3811312
The documentation isn't helpful enough for me to understand the difference between these.
It's like concatMap, but maps each value always to the same inner
Observable.
http://reactivex.io/rxjs/file/es6/operators/concatMapTo.js.html
I tried checking out learnrxjs.io's examples on stackblitz, but even with those, I wasn't able to immediately identify what the distinguishing feature was separating these.
FYI i saw this other similar question
What is the difference between mergeMap and mergeMapTo?
but the answer in there wasn't satisfactory, because in the learnrxjs.io examples, they clearly map to observables, not hard-coded values.
https://www.learnrxjs.io/operators/transformation/concatmapto.html
If someone could provide some examples (and maybe a brief explanation) to help distinguish the *** vs the ***To higher-order observable operators, I'd appreciate that, thanks.
rxjs rxjs6
rxjs rxjs6
asked Nov 10 at 14:48
squirrelsareduck
3811312
asked Nov 10 at 14:48
squirrelsareduck
3811312
asked Nov 10 at 14:48
squirrelsareduck
3811312
asked Nov 10 at 14:48
squirrelsareduck
3811312
asked Nov 10 at 14:48
squirrelsareduck
3811312
3811312
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
3
down vote
accepted
Simply said, variants with *To will always use the same Observable that needs to be created when the whole chain is created regardless of the values emitted by the chain. They take an Observable as a parameter.
Variants without *To can create and return any Observable only when their source Observable emits. They take a callback as a parameter.
For example when I use mergeMapTo I'm always subscribing to the same Observable:
source.pipe(
mergeMapTo(of(1)),
)
Every emission from source will always be mapped to of(1) and there's no way I can change that.
One the other hand with just mergeMap I can return any Observable I want depending on the value received:
source.pipe(
mergeMap(v => of(v * 2)),
)
Maybe an easier way to think about this is to remember that *To variants map a value to a constant (even when it's not a "real JavaScript constant").
answered Nov 10 at 15:02
martin
39.8k1180124
1
thanks! took me a while to understand your answer, but now i get it. the *To ones take an observable as the direct argument, whereas the ones without the *To suffix take a function as the direct argument (and that function could conditionally return various, different observables depending on given conditional logic).
– squirrelsareduck
Nov 10 at 15:42
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
Simply said, variants with *To will always use the same Observable that needs to be created when the whole chain is created regardless of the values emitted by the chain. They take an Observable as a parameter.
Variants without *To can create and return any Observable only when their source Observable emits. They take a callback as a parameter.
For example when I use mergeMapTo I'm always subscribing to the same Observable:
source.pipe(
mergeMapTo(of(1)),
)
Every emission from source will always be mapped to of(1) and there's no way I can change that.
One the other hand with just mergeMap I can return any Observable I want depending on the value received:
source.pipe(
mergeMap(v => of(v * 2)),
)
Maybe an easier way to think about this is to remember that *To variants map a value to a constant (even when it's not a "real JavaScript constant").
answered Nov 10 at 15:02
martin
39.8k1180124
1
thanks! took me a while to understand your answer, but now i get it. the *To ones take an observable as the direct argument, whereas the ones without the *To suffix take a function as the direct argument (and that function could conditionally return various, different observables depending on given conditional logic).
– squirrelsareduck
Nov 10 at 15:42
add a comment |
up vote
3
down vote
accepted
Simply said, variants with *To will always use the same Observable that needs to be created when the whole chain is created regardless of the values emitted by the chain. They take an Observable as a parameter.
Variants without *To can create and return any Observable only when their source Observable emits. They take a callback as a parameter.
For example when I use mergeMapTo I'm always subscribing to the same Observable:
source.pipe(
mergeMapTo(of(1)),
)
Every emission from source will always be mapped to of(1) and there's no way I can change that.
One the other hand with just mergeMap I can return any Observable I want depending on the value received:
source.pipe(
mergeMap(v => of(v * 2)),
)
Maybe an easier way to think about this is to remember that *To variants map a value to a constant (even when it's not a "real JavaScript constant").
answered Nov 10 at 15:02
martin
39.8k1180124
1
thanks! took me a while to understand your answer, but now i get it. the *To ones take an observable as the direct argument, whereas the ones without the *To suffix take a function as the direct argument (and that function could conditionally return various, different observables depending on given conditional logic).
– squirrelsareduck
Nov 10 at 15:42
add a comment |
up vote
3
down vote
accepted
up vote
3
down vote
accepted
Simply said, variants with *To will always use the same Observable that needs to be created when the whole chain is created regardless of the values emitted by the chain. They take an Observable as a parameter.
Variants without *To can create and return any Observable only when their source Observable emits. They take a callback as a parameter.
For example when I use mergeMapTo I'm always subscribing to the same Observable:
source.pipe(
mergeMapTo(of(1)),
)
Every emission from source will always be mapped to of(1) and there's no way I can change that.
One the other hand with just mergeMap I can return any Observable I want depending on the value received:
source.pipe(
mergeMap(v => of(v * 2)),
)
Maybe an easier way to think about this is to remember that *To variants map a value to a constant (even when it's not a "real JavaScript constant").
answered Nov 10 at 15:02
martin
39.8k1180124
Simply said, variants with *To will always use the same Observable that needs to be created when the whole chain is created regardless of the values emitted by the chain. They take an Observable as a parameter.
Variants without *To can create and return any Observable only when their source Observable emits. They take a callback as a parameter.
For example when I use mergeMapTo I'm always subscribing to the same Observable:
source.pipe(
mergeMapTo(of(1)),
)
Every emission from source will always be mapped to of(1) and there's no way I can change that.
One the other hand with just mergeMap I can return any Observable I want depending on the value received:
source.pipe(
mergeMap(v => of(v * 2)),
)
Maybe an easier way to think about this is to remember that *To variants map a value to a constant (even when it's not a "real JavaScript constant").
answered Nov 10 at 15:02
martin
39.8k1180124
edited Nov 10 at 16:18
answered Nov 10 at 15:02
martin
39.8k1180124
answered Nov 10 at 15:02
martin
39.8k1180124
answered Nov 10 at 15:02
martin
39.8k1180124
39.8k1180124
1
thanks! took me a while to understand your answer, but now i get it. the *To ones take an observable as the direct argument, whereas the ones without the *To suffix take a function as the direct argument (and that function could conditionally return various, different observables depending on given conditional logic).
– squirrelsareduck
Nov 10 at 15:42
add a comment |
1
thanks! took me a while to understand your answer, but now i get it. the *To ones take an observable as the direct argument, whereas the ones without the *To suffix take a function as the direct argument (and that function could conditionally return various, different observables depending on given conditional logic).
– squirrelsareduck
Nov 10 at 15:42
1
1
thanks! took me a while to understand your answer, but now i get it. the *To ones take an observable as the direct argument, whereas the ones without the *To suffix take a function as the direct argument (and that function could conditionally return various, different observables depending on given conditional logic).
– squirrelsareduck
Nov 10 at 15:42
thanks! took me a while to understand your answer, but now i get it. the *To ones take an observable as the direct argument, whereas the ones without the *To suffix take a function as the direct argument (and that function could conditionally return various, different observables depending on given conditional logic).
– squirrelsareduck
Nov 10 at 15:42
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53240090%2frxjs-concatmap-vs-concatmapto-mergemap-vs-mergemapto%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
