Category: Subjects

Using a Subject to emit data is something we do a lot in Angular applications, and more often than not, what we try to emit is the result of an HTTP request, such as:

While the above works perfectly well, it’s important to know that the subscribe method of an Observable takes either a function as a parameter (which is what I’ve done in the previous example) or an object that implements the Observer interface. We touched on that interface earlier to illustrate exciting things we could do with the tap operator.

The thing is that Subjects implement that interface, so we can simplify our earlier code into:

This isn’t just a syntax improvement, as writing less functions results in better overall Javascript performance. Less code to ship = less code to download = less code to interpret and store in memory for the browser = faster user experience. You can see a code example here on Stackblitz.

We introduced RxJs Subjects a few weeks back.

BehaviorSubject

The most common type of Subject used with Angular is BehaviorSubject. Why is that? Because a BehaviorSubject has two exciting features that a plain Subject does not have:

• It starts with a default value, which means it is never empty.
• When we subscribe to a behavior subject, it will immediately give us the last emitted value.

Imagine subscribing to a magazine and receiving its latest published issue immediately. That’s what a BehaviorSubject does. This is helpful if you have components that need to know about the app’s current user. When the component subscribes to the “current user,” we want to get that info immediately and not wait for the next user update.

Also, since behavior subjects always have a value, they have a getValue() method that synchronously returns the current value.

ReplaySubject

A ReplaySubject is very similar to a BehaviorSubject, with two key differences:

• No default value
• Can replay more than just the last value

The constructor parameter determines how many values should be replayed to new subscribers:

Subject

A plain Subject has none of the above capabilities. When a value is emitted, current subscribers receive it, but future subscribers won’t. There is no replaying of the latest value(s), which makes plain Subjects less interesting to work with.

Our RxJs topic for this week is going to be Subjects. Angular has multiple services and classes (such as FormControl) that give us access to Observables that we can subscribe to. But what if we want to create our own Observable to emit data?

While there is an Observable constructor and Observable creation functions such as of and from, none of these solutions are as powerful and feature-complete as using a Subject.

Why is that? Because Subjects check a lot of boxes for us:

• They are multicast, which means they support multiple subscribers out of the box (an Observable does not by default)
• They can replay values to new subscribers (BehaviorSubject and ReplaySubject do that)

Those two features are critical when building Angular apps because our data is usually handled by services, then consumed by components. For example, suppose a service fetches some data (say, the user session info upon login). In that case, it is essential for components that will be displayed later on the screen to subscribe to that information and get the current session info right away (that’s why replayability/caching the latest value is critical).

As a plus, the Subject API is incredibly straightforward:

So we have complete control over what we emit, when, and how. All with a single method: .next()

And since a Subject is a specific type of Observable, you can subscribe to it the same way: subject.subscribe(). That said, it is a best practice to expose the subject as an Observable by using the asObservable() method as illustrated here:

For more details on how to use Subjects and what are the different types of Subjects, feel free to head to my RxJs subjects tutorial.