Make Observables hot only where necessary
Operators like publish(), refCount(), share() make it easy to convert a cold Observable to a hot one, and are often necessary to get some feature done. In this lesson we will learn when exactly do we need to convert to hot, and when can we leave the Observable cold.
Why not just have a single share after random, why also in the set interval
Hi cyberdyme, that's in order to share the setInterval with multiple subscribers. Without share there, you would notice the problem once a second subscribe happens at a different time (say 200 ms) after the first subscribe, because you would have two setInterval timers ticking at different times and producing random numbers.
I find that a bit confusing only because it seems like you're suggesting that it's required in order to get this specific example to work correctly. Assuming that the clock$ variable is private and internal (and if we could somehow guarantee no other subscribers to that observable) it should be enough just to share the result of the map on the random$ and be done.
I think the suggestion may be that since clock$ is independently available for subscription elsewhere that share is a good idea, but technically it's not required for this example. Is that correct?
More specifically, if random$ was defined using Rx.Observable.interval(500).take(6) directly instead of in terms of clock$ then only one share is needed after the random number calculation -- not after both the take(6) AND the random mapping.
As always, though, these videos are awesome. Thanks for putting them together.
Hi Mike. Yes your thought process is correct. The idea in this lesson was showing how some operators (like map or filter) never need to be shared, because they are pure and yield the same results independent of subscriptions. Some operators or factories are impure, and these may need to be shared. The example in question is of course contrived, but the lesson is to identify the impure parts that may need sharing.
To heed to the lessons of this video, would events streams associated with input such as mouse theoretically be a candidate of also making sure is shared once multiple subscribers are involved?
Hi Kevin. Typically if we share an Observable that already represents a hot source, like mouse clicks, the result behavior stays the same. That said, it may still be wise to share that Observable since then you avoid adding multiple event listeners to the underlying DOM API (element.addEventListener()).
Hi, like your courses very much! Here I am still not quite get why clock$ also need to add .share() :(
Q: If I share randomNum$, does it mean clock$ also get shared?
Get bit more confused about "second subscribe happens... say 200ms) after the first subscribe..... two setInterval timers ticking...."
Q: If the source is not yet completed, no matter how many subscribers, they still share the same source, right? So after 200ms of first subscriber, the source is not yet completed... confused why there are two timers?
Hi Zhentian! I'm here to help.
The first question you made should be answered above in this thread, someone else had the same question.
The second question can be answered as: if the cold source is not yet completed, each subscriber will invoke its own exclusive execution of the source, so there is no sharing. This is fundamentally what cold means: no sharing happens at all. For more information on the topic of hot and cold, you can read this https://staltz.com/cold-and-hot-callbacks.html
Very good explanation! I couldn't get why we have to share interval Observable, I thought that just the randomNum$ would do the trick.
You don't need a .share() on the clock$ observable. The .share() on the randomNum$ observable is sufficient for this example.
Great course. Thank you Andre for that stuff.