Advantages of the Reactive Pattern

You might have guessed the first advantage: we don’t have to manually manage subscriptions and unsubscriptions, and what a relief! But there are a lot of other advantages; it’s not only about the async pipe. Let’s look at the other advantages in more detail.

Using the declarative approach

Let’s shed light on the fact that we don’t explicitly use the subscribe() method. What’s wrong with subscribe()? Well, subscribing to a stream inside our component means we’re allowing imperative code to leak into our functional and reactive code. Using the RxJS observables doesn’t make the code reactive and declarative systematically. But what does declarative mean, exactly?

Well, first, we’ll nail down some key terms. Then let’s iterate from there.

• Declarative refers to the use of declared functions to perform actions. We rely upon pure functions that can define an event flow. With RxJS, we can see this in the form of observables and operators.

• A pure function is a function that will always return identical outputs for identical inputs, no matter how many times it’s called. In other words, the function will always predictably produce the same output.

So why should we care? Well, we should care because the declarative approach using RxJS operators and observables has many advantages, namely the following:

• It makes the code cleaner and more readable.
• It makes the code easier to test because it’s predictable.
• It makes us able to cache the stream output given a certain input, and this will enhance performance. We’ll explore this in more detail in Multicasting Essentials, Caching Streams, and Sharing Data between Components.
• It enables us to leverage RxJS operators and transform and combine streams coming from different services or even within the same service. We’ll see this in Transforming Streams.
• It helps us react easily to user interactions in order to execute an action.

So more declarative means more reactive. However, be careful. This doesn’t mean we can’t ever call the subscribe() method. It’s unavoidable in some situations to trigger the observable notifier. But try to ask yourself, “Do we really need to subscribe here? Can we instead compose multiple streams together or use RxJS operators to achieve what I need without subscribing?” Aside from cases where it’s unavoidable, never use subscribe().

Now let’s move to the performance advantages.

Using the change detection strategy of OnPush

The other really cool thing is that we can use the changeDetection strategy OnPush. Change detection is one of the powerful features of Angular. It’s about detecting when the component’s data changes and then automatically rerendering the view or updating the document object model (DOM) to reflect that change. The default strategy of “check always” means that whenever any data is mutated or changed, Angular will run the change detector to update the DOM. So it’s automatic until explicitly deactivated.

In the OnPush strategy, Angular will only run the change detector when the following occurs:

• Condition 1: A component’s @Input property reference changes. (Bear in mind that when the input property object is mutated directly, then the reference of the object will not change, and consequently, the change detector will not run. In this case, we should return a new reference of the property object to trigger the change detection.)

• Condition 2: A component event handler is emitted or gets triggered.

• Condition 3: A bound observable via the async pipe emits a new value.

Therefore, using the changeDetection OnPush strategy minimizes any change detection cycles and will only check for changes to rerender our components in the preceding cases. This strategy applies to all child directives and cannot be overridden.

In our scenario, we only need the change detector to run if we get a new value; otherwise, we get useless updates. So our scenario matches Condition 3. The good news is that we can use the change detection onPush strategy as follows: