Cold vs Hot Observables by thoughtram
- What we rather want is that new subscribers see exactly the old values that were already emitted earlier.
- It’s because the subscription to the underlying source is only made once that we have a first subscriber to the ConnectableObservable .
- log ( “1st subscriber:” + v )); setTimeout (() // delay for a little more than a second and then add second subscriber => obs .
- We use publish to share the value producer across several subscriptions (one indicator of being hot!
- So by the time that our two subscribers start listening the value has long been pumped through.
In this article we are going to demystify what the term hot vs cold means when it comes to Observables.
@smokenight: Cold vs. Hot Observables – @thoughtram @angularjs
Contents are based on Angular version >= 2.x unless explicitely stated differently.
One of the most exciting topics around Angular is it’s relationship to Observables. It’s such an essential part of the framework that we cover a fair amount of Observable knowledge in our Angular Master Class. That said, the topic is so big that one could easily run a 3-days workshop on Observables itself.
There’s one particular area of Observables that we don’t explicitly touch on in our workshop but that keeps coming up in questions every single time that we teach them.
Want to see things in action first?
Understanding the nature of hot and cold Observables is a crucial part to master Observables. Before we try to explore the topic through some practical examples, let’s read through the definition from the RxJS project itself
Ok, so far so good. Let’s see what that means in practice.
. We make two independent subscriptions to the same Observable and print out the output with a prefix so that we can tell them apart.
When we run this code we’ll see the following output in the console.
instead. If that was the case, we wouldn’t be able to tell whether it’s cold or hot. And that’s one important thing to understand. It’s not always possible from the subscriber side to know whether you are dealing with a cold or hot Observable.
and see what happens.
If we run that code again we’ll notice that we actually get different output per subscription. Notice the change in the last digit.
. In other words, the Observable started producing the values upon each subscription which makes it cold by definition.
Now that we know that our Observable is clearly cold, let’s try to warm it up a little.
operators for a moment and solely focus on the output.
) created upon subscription. But it’s cold in the sense that it doesn’t start producing values before the subscriptions exist.
call before the subscriptions.
is really really hot as in it produces values no matter if anyone listens or not. So by the time that our two subscribers start listening the value has long been pumped through.
better, let’s use an Observable that will produce infinite values instead of just a single one.
The setup we use is slightly more complex from what we had before, so let’s break it down.
for now as we’re going to explain it later.
We see the following output as we run the script.
to share the value producing source across subscribers.
at all because they would have been emitted before we start to listen, right?
Let’s try out and run this code instead.
ourselves early on.
when we run this code.
This means we now have a truly hot Observable that produces values no matter if someone listens or not.
As we’ve seen the question whether an Observable is hot or cold is everything but black and white. In fact there are several strategies how values may be pushed to subscribers that we didn’t even touch on yet. In general we can say that we should be dealing with a hot Observable whenever we subscribe to something that is generating values no matter if someone is listening or not. When we subscribe to such a hot Observable, we don’t see past values but only new ones that were generated after our subscription.
events. The mouse moves happen regardless if someone is listening or not. When we start listening for them, we only get future events.
Cold Observables on the other hand are the lazy ones. They only start producing values when someone subscribes. But then again, it’s really not a black and white thing. An iced cold Observable starts reproducing the values it emits independently with every new subscriber as we’ve seen in the examples above. But how should we call an Observable that only starts generating values as the first subscriber subscribes and then shares and reemits the exact same values to every new subscriber? Things get blurry and categorizing only by cold and hot doesn’t really cut it for every possible use case.
file from a server and renders the contacts as a list in the template.
property holding the collection of contacts.
Now the interesting question is: What happens if we’d subscribe to it twice by adding another list to our template?
operator and adding it as the last operator to our Observable causes the second request to vanish.
But let’s not fall back to Promises just yet. With all our knowledge regarding cold and hot Observables we should be able to simply fix our Observable so that it shares one single subscription to the underlying source – the Observable that issues the HTTP call.
That should do it, right? Well, almost. We can see that there’s no second request anymore. But there’s still a big issue that makes the code behave quite differently from what we are used with Promises.
Consider we’d want the second list to show up after a delay of 500ms. We could change the code to this.
after 500ms. But when we run the code, we notice that our second list isn’t showing up!
Now when we run that code we see our second list after 500ms but we still don’t see a second request. In other words, we created an Observable that emits upon subscription with the data that was fetched with the first request.
Whew! We came a long way. We hope this gives you a clearer picture of what the term hot vs cold actually means when it comes to Observables.