Multiple Subscribes to One Observable

[00:00:00]
>> Jafar Husain: Here's an interesting question. If I call subscribe three times on the one timeout observable I get. So if I go,
>> Jafar Husain: Submit, just go ahead and print this out.
>> Jafar Husain: So if I do this, I think we'd all expect that I get done, right? Or let's just write this, cuz it's gonna on next, me and undefined.

[00:00:55]
So let's give that a shot. What the hell? We're doing it live here. So hey, all right, we got an observable. Now, we're cooking, right? So if I was to call subscribe three more times on the same observable, what do we think would happen?
>> Jafar Husain: Anyone want to hazard a guess?

[00:01:16]
No wrong answers. Well, there are wrong answers, but we won't give you a hard time about it.
>> Speaker 2: So you're subscribing to the same observable three times you're saying?
>> Jafar Husain: Yeah, how many setTimeouts am I gonna get?
>> Speaker 2: One setTimeout, but three next and dones.
>> Jafar Husain: So that is a very, very common misconception.

[00:01:44]
And it's very common, and that's why we're doing this. So let's actually see what happens when we run this twice. Just get it twice, cuz it'll be easier to debug. So I'm gonna do this frequently here. We're gonna set up a debugger, and that's how we're gonna figure out what's actually going on under the hood with our observable.

[00:02:08]
And I will pump up that font size. So there's a little garbage in here from jsbin which you can just ignore. So we see there's two subscriptions. Can I even see my,
>> Jafar Husain: I do not have my debugging, I guess cuz this is two-bit, there we go. If you can't see that let me know.

[00:02:42]
But let's see what happens when we step in to subscribe here. Oops! We hopped into the subscribe method that every observable gets. But remember, that's just a little hop and skip and a jump to the real definition of subscribe that was passed in here on the constructor. So now, we make it into our real definition of subscribe for this timeoutObservable.

[00:03:03]
Does everybody see how that happened? Take a moment. Right, we're here and what are we doing? Well, we're calling setTimeout. Cool, and I'm gonna step over that. And that setTimeout's gonna hit eventually. We're gonna return our subscription and where do we find ourselves? Well, wait a second, now, we're out to the next subscribe, right?

[00:03:22]
Cuz the setTimeout hasn't hit yet. It's waiting, and when we step in here and step in there, wait a second. We found ourselves to calling a second setTimeout, right? Why did this happen, right? Maybe our intuition was we were only gonna get one setTimeout and two subscriptions to that setTimeout.

[00:03:42]
Well, this goes to the nature, the very nature of what an observable is, it's a function in object clothing. It's actually just a function, subscribe's a function. If you create a function called write to the console, and call it twice, how many times are you gonna write to the console?

[00:04:00]
Twice, right? We can see from this simple definition that our friend observable is nothing but a function with an object wrapper, right? So, oops.
>> Jafar Husain: Let's take another look, right? What have we done when we've created an observable? We've just created a wrapper, it has a function on it.

[00:04:22]
And if we call that function twice, all the logic in that function gets executed multiple times and this is something we call laziness, right? A function is kinda lazy. It's not gonna do anything until you call it. But if you call it multiple times, you're gonna get multiple side effects.

[00:04:39]
And so today we're gonna talk a little bit about side effects, cuz sometimes they're a little bit unexpected. And this is an interesting difference between observable and for those here who are familiar with them, promises, right? If you subscribe to the same promise multiple times using then, you're not actually gonna get additional side effects.

[00:04:54]
But with observable, you might. And so there are ways in which you can effectively make sure that you don't get three or four, five sets of the same side effects for an observable. And we'll talk about that later today, it's called subjects. But it's also, can anybody tell me why it might be useful to repeat side effects when you subscribe to the same observable?

[00:05:14]
Isn't that always kinda just a waste of time?
>> Speaker 3: Different components might have different needs in observable.
>> Jafar Husain: Well, but if you have, that's true, but if you have just an observable. All you can do is listen to it, right? You can't really affect the data that comes out of it by the time you have one observable, right?

[00:05:30]
With timeout, we can create a new observable that fires after a certain amount of time. But once you have that observable, right? If three different components have the same observable, they can't really impact what comes out of it. So why would you want say three network requests when subscribing to one observable three times, cuz that's the implication of what we're talking about here.

[00:05:49]
If I have an observable that fires a network request, and I've subscribed to it three times, I'm gonna get three network requests. So this is one of the things that catches developers off guard. Can any of you think of a good reason to do it though?
>> Speaker 4: If it was, if you had like a hot observable and like you needed data for everything that subscribed, maybe you would need to make another request.

[00:06:13]
>> Jafar Husain: Well, let's talk about what you mean by hot observable, cuz it's a really interesting idea here. A hot observable and a cold observable are some terms we use to help us understand the behavior of an observable. A cold observable is really simple to understand. No matter how many times you subscribe to it, you always get the same result, right?

[00:06:33]
That's a cold observable. A hot observable, depending on when you subscribe to it, you might actually get different data. Can anybody think of an example of a hot event stream? Like maybe in the browser.
>> Speaker 4: Click handlers.
>> Jafar Husain: Click handlers, right. I mean, or mouse move, or any of these events.

[00:06:51]
We know that if I start listening to an event seven seconds later, I might miss a bunch of events, right, just good common sense. But let's take a look at our timeout observable. Am I ever gonna miss the timeout, no matter when I subscribe to this observable. So let's take a look down here, right?

[00:07:10]
Let's actually put this whole thing to setTimeout.
>> Jafar Husain: If I wait five seconds, am I gonna miss the timeout notification? If I wait five seconds before subscribing to the observable, am I gonna miss the timeout notification? Who thinks yes? Who thinks no?
>> Speaker 5: I think no, because it looks like when we subscribe is when it actually sets the timeout.

[00:07:49]
>> Jafar Husain: Right, the thing about this observable is that it doesn't do the work until you actually subscribe. And that's why in this context, it's a cold observable. And that's typically how functions work, right? They don't do anything until we call them. So because observable's just really a thin wrapper for a subscribe method, any work you do inside of that subscribe method, as long as you kick it off when we subscribe, then you're always going to get the result.

[00:08:15]
So notice that the timeout doesn't get created. All right, we don't call setTimeout when this happens, right? We know that because when we step through, when we did this, we didn't do a damn thing, right? All we did was we created an observable, and that's really just a function waiting to be called.

[00:08:35]
And that's how observable does laziness, that's how we can map, and filter, and reduce, and scan. We haven't really done anything, though. Because all we've done is we've built up a bunch of functions which hold on to each other waiting to be called. And how do we actually call the observable?

[00:08:51]
How do we get it to do things, what function? Subscribe, absolutely, and that's lazy evaluation. It's not doing work until you absolutely need to do it. So now, we've seen an example of a cold observable. And the reason it's a called observable is it waits patiently, doesn't do a damn thing until we subscribe, right?

[00:09:13]
What's an example of a hot observable? I think we already heard one, it's event streams, right? So let's build that next, let's make a way of creating an observable based on DOM events.