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.
Thanks for putting this up here, great to know!
@Sam, flatMapLatest is giving me an error, "start$.flatMapLatest is not a function", on version "5.0.0-beta.6"
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()
start$
.switchMapTo(intervalThatStops$)
.mapTo<any>(inc)
.startWith(data)
.scan((acc, curr) => curr(acc) )
.subscribe((x) => console.log(x));
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?
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
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:
.mapTo(inc)
This is cleaner and better communicates the intention.
I made the following minor changes when working with RxJS 4.0.6: