Changing Behavior with MapTo

John Lindquist
InstructorJohn Lindquist

Share this video with your friends

Send Tweet
Published 7 years ago
Updated 4 years ago

You often need streams to trigger different behaviors on the data based on which streams triggers. This lessons shows how to use mapTo to pass functions into the scan operator and have completed control over you data.

[00:00] Right now, my stream is stuck with this one behavior in scan where it simply adds one to the count and returns a new object, but we can actually extract this out to make it more flexible and use different behaviors.

[00:12] If I cut this, and we'll call it inc. I'll just say assign it to this. I can easily make this a one line of code thing. I'll delete return, delete the curlies, and one line arrow functions that only return an object need parens around them or else it will treat the curly braces as a block. Just add the parens and you're fine.

[00:35] I can drop the inc in the scan, hit save, and I'll hit start, and stop, and we're good to go. Start and stop.

[00:45] You can imagine if I had something like a reset behavior. We'll say reset, which instead of returning an object with a count plus one, we'll go ahead and return the original data. It will set it back to this. Then I can change this to reset, hit save, I'll hit start, and then this will just keep on logging out count zero as expected.

[01:08] What we need to do to make scan flexible enough to switch between these on its own is to pass a function down the stream. If I say I want the output of my current interval to map to a function, in this case increment, I would need to tell scan that now we have an accumulator and a current and that the current value is that function and the accumulator is that original state we started with.

[01:36] I hit save and now I'll hit start. It works just the same. I'll hit stop and start and stop.

[01:45] Just to be clear, this interval is passing this function into scan each time as the current and then the current, which is this function here, is taking the accumulator and then returning that object just as we did before.

[01:59] If I don't map to and I log this out, so I'll return just the current, you'll see now that the current is, when I hit start, just the tick going through of zero, one, two. That's coming from the interval.

[02:14] We don't want that. We don't want the interval. What we want is the function, so mapto inc and then we have a function here instead of the tick, which can operate on the accumulator.

[02:27] Hit save. I'll hit start. Now we're back to that original behavior.

Sam De Boni
Sam De Boni
~ 7 years ago

I made the following minor changes when working with RxJS 4.0.6:

  1. use flatMapLatest in place of switchMapTo
  2. use map in place of mapTo
  3. assign a function to inc that returns the increment function since map evaluates its argument
<pre> const Observable = Rx.Observable; const startButton = document.querySelector('#start'); const stopButton = document.querySelector('#stop'); const start$ = Observable.fromEvent(startButton, 'click'); const interval$ = Observable.interval(1000); const stop$ = Observable.fromEvent(stopButton, 'click'); const intervalThatStops$ = interval$ .takeUntil(stop$); const data = {count:0}; **const inc = ()=>(acc)=>({count:acc.count+1});** const reset = (acc)=> data; start$ **.flatMapLatest(intervalThatStops$)** **.map(inc)** .startWith(data) .scan((acc,curr)=> { return curr(acc); }) .subscribe((x)=>console.log(x)); </pre>
nader dabit
nader dabit
~ 7 years ago

Thanks for putting this up here, great to know!

nader dabit
nader dabit
~ 7 years ago

@Sam, flatMapLatest is giving me an error, "start$.flatMapLatest is not a function", on version "5.0.0-beta.6"

Noah Rawlins
Noah Rawlins
~ 7 years ago

with rxjs 5.0.0 beta 7 I had to do this to get his behavior. Note the <any> type on the mapTo. This makes sure it doesn't complain about trying to start an Observable that now emits functions with a plain object in startWith()

  .scan((acc, curr) => curr(acc) )
  .subscribe((x) => console.log(x));
~ 5 years ago

I didn't understand your intention on 01:08:

What we need to do to make .scan() flexible enough to switch between these on its own is to pass a function down the stream.

In the end of the example I don't see scan function switching between behaviours, but the whole thing is much harder to read now. Can you point me maybe to another example where I can see the need of such change?

~ 4 years ago

Why .mapTo instead of .map? you don't make clear what .mapTo IS and why to use... can you clarify? The only way i can understand what you say is that, .map will process each event in the stream with the passed-in function and send the result of that downstream,... whereas .mapTo sends the passed-in function itself ('inc') downstream without processing each event. is this true? thanks

J. Matthew
J. Matthew
~ 4 years ago

Why .mapTo instead of .map? you don't make clear what .mapTo IS and why to use...

To quote mapTo's documentation: Like map, but it maps every source value to the same output value every time.

In other (more) words, you'd typically use map to modify the incoming value in some way, e.g.

[1,2,3].map(x => 2 * x) = [2,4,6]

But in this case we don't use or care about the incoming value; we just want to replace it entirely, using the same constant each time. In this case we're replacing it with a function, inc. We could still do this with map:

.map(x => inc)

But we're not using x, so it doesn't need to be there. We could also do:

.map(() => inc)

But we're still writing a function when all we want to do is return inc. That's why mapTo exists:


This is cleaner and better communicates the intention.