Move important side effects from do() to subscribe()

[00:00] If you haven't heard of the do operator it allows us to perform a side effect in a specific point here in the chain of operators. In this example a click here will update the dot position but it will also cause request to happen to the server and get the response back.

[00:18] How does do work? It's actually similar to a map operator where we take the input event and then we can simply return that same input event. Basically this done nothing. Every event that comes in will be the same that comes out, so it really does nothing. We can also include a side effect here.

[00:42] Do does the same thing as this map. As you can see that allows us to add the sneaky side effect. Do is just a shortcut so that we don't need to write these lines of code. Basically do causes a sneaky side effect to happen during the data flow of this chain. This sneakiness may become a problem.

[01:04] For instance, what if this part would be named as c stream for clicks and then in another file we use that c stream like this. We think that c stream is just an observable of click events, when in fact every time that we observe it, it causes this side effect. There is some sneakiness going on there.

[01:26] In another sense, when we read this code it seems like data comes from this source, passes through these operators and ends in this destination. It seems like there is just one destination, but in fact there are two destinations of data where data comes from here but it also lands here as a destination in order to update the dot position.

[01:49] As you can see these things are not so obvious. In fact we can refactor this code to avoid a do and we can use another subscribe. We're going to start by first noticing that this isn't anonymous observable. I didn't assign it to some const.

[02:06] Also, when we call an operator this will be another observable which is anonymous. Let's give some names for these. Let's call this click stream. Then now we can subscribe to that click stream.

[02:23] Notice that I didn't even change the contents here because it's basically the same for do and for subscribe. Now, we can create a response stream that will be this click stream switch mapped to this Ajax. Then we can subscribe to the response stream in order to get that data.

[02:47] Notice how with this exercise where we named each of these sources of data now things are bit more explicit where we have this source of data and we subscribe to it to get that data and put it in this destination.

[03:00] Then we also this source of data which depends on that source of data, and we subscribe to that one to give data to that destination. Notice also that if I replace subscribe with do this won't actually perform the side effect, because remember do is almost like a map, and as you know map will return an observable.

[03:21] This will return an observable, but we're not subscribing to that one, we're just dropping it on the floor. That's why this will never happen if we have the do here. That's why we need to have a subscribe.

[03:33] As you can see we got rid of our do and our code will still work in the same way. We will update the dot position and we're also going to make requests to the server. That said, there are good use cases for do, and I would recommend that you use do for debugging. We can put here whenever we get an event we can console log that event's client ex-position.

[04:01] Now, when we click we also log out the ex-position here. We also do the side effects. Use do for debugging, it's very convenient, because the sneakiness of a console log is not a problem since it's just for debugging.

[04:19] The lesson is, make the pipeline of sources of data and destinations of data more explicit by using subscribe more often than using do.