Inspect the Behavior of Operators with RxJS do
inspect the behavior of other operators
We just saw map which is a transformation operator. There are a couple of categories of operators, such as filtering, combination, flattening, etc. One of these categories is the utility operators. The most important utility operator is do, useful for debugging.
🚨 Since we are importing interval from RxJS, we don't need to preface our Observables with Rx.Observable. do is deprecated, use tap instead. You can no longer .{operator}, you need to .pipe({operator}) instead.
[00:00] We just saw map, which is a transformation operator. There are a couple of categories of operators, such as transformation, but also filtering, combination filtering, etc.
[00:11] One of these categories is the utility operators. The most important utility operator is do. Do is very similar to map. It also takes a function, but it does this. You get that X as an input, but you don't need to return anything. Actually, if you do return, then that return will simply be ignored.
[00:35] Inside here, you can do, for instance, a console log outputting that, and if you return anything, that will just be ignored. Do is actually similar, or equivalent, actually, to foo.mapped, where this function X will simply immediately return X, but it will also on the side run that console log for you.
[01:01] Do is just a special case of map, where you are returning the same value that you received. In case we return 10 here, do will just ignore what you did, and it will anyway return X.
[01:17] What is the point of having do if it's actually not transforming that value at all, it's just returning the same value? Do is really useful for debugging purposes. You can do something like this, you can apply do, take that X value, and you can put in console log something like before, and that value. That will return you an observable that looks like the same thing, because it just returns the same X value.
[01:49] Then we can call map, and after we have that mapped observable we can run again do, which will give us the same observable as this input here, like that. But here, we can say after. Before and after will tell us what was the value before we called map, and what was the value that came out of map.
[02:17] If we write our code like our marble diagrams, we're going to have X, which we'll call the console log, saying before. We're returning this, but this will be anyway ignored by the do, and it will anyway return X. That's the idea.
[02:39] Then we also do the map to multiply by two. Then we run again do with an after. Now this is bar as an observable, and if we run this, we're going to see before and after being called between this map. Then you can see clearly that before calling map, the value was one. After calling map, the value was two.
[03:11] Now, it's important to notice that do does not trigger a subscription. That's important because do is not supposed to call or trigger anything to happen. It simply exists as a spy in order to inspect what happened.
[03:26] Remember, a subscription means giving values, but do doesn't mean that. Do operator means if the observable source delivers values, then please silently run also this function on the side.
[03:43] In fact, if I comment this out, none of these console logs will be called. That's important to remember, because do is in the subscription chain. It means that once we subscribe to bar, then this will be subscribed and that will be subscribed, and that will be subscribed, and this is how these will be run.
[04:06] That's why do is a great tool to use for replacing console log, for debugging, and we may use them in upcoming lessons to inspect the behavior of other operators, especially in this fashion where we put dos as a sandwich here around the operator that we want to understand.
Hi Kevin. Glad to hear you are learning!
I would recommend putting impure code as such in subscribe(), not do(). There are a few cases where you could use do() for impure code, but mostly they should go to subscribe(). There is an upcoming course I made (already fully recorded) which will soon be put on Egghead that teaches exactly about do() vs subscribe(). Stay tuned.
Hello Andre,
I love the series you put up here, every lesson I learn about RxJS makes me fall in love more and more with Reactive Programming. I have a question concerning the do() operator. I read that all unpure behavior like logging, changing button states, writing to local storage should be wrapped in the do() operator. Is this the general practice or are there better alternatives for this?
Kind regards, Kevin