The Problem with Cold Observables

• Why do I want to read this?
  • This chapter tackles two big things: multiplexing observables, and building an Observable infrastructure for one’s application.
• What will I learn?
  • The difference between hot/cold observables and when to use each, as well as how they fit into a full application.
• What will I be able to do that I couldn’t do before?
  • Take information from a single source and pass it out to many subscribers all at once.
• Where are we going next, and how does this fit in?
  • A purely Rx architecture isn’t pretty - next, we’ll learn how to use Angular to structure a fuller application.

Cold observables

So far you’ve learned that a new subscriber creates an entirely new observable stream, including rerunning the constructor. The term for this kind of observable is a cold observable, and it’s the default in RxJS.

Hot observables

However, sometimes you may want to create only a single source for an observable stream (such as the web socket example in Advanced Async).

You don’t want to create a pile of new web socket connections if all of a page’s components want to listen to the stream. In this case, you need a hot observable.

Multicasting

A hot observable contains a single stream that every subscriber listens to. This is called multicasting.

publish

These hot observables can be created by piping through publish on a regular observable or by creating a subject, which is hot by default.

This sounds complicated, but if you take it step-by-step, you’ll do just fine. You’ll learn these concepts by building this chapter’s big project: a chat system. Time to dive in!

The Problem with Cold Observables

Let’s see what the problem with cold observables is.

Creation Function

So far, you’ve learned that each new subscription to an observable runs the root creation function: