Why unsubscribe from Observables?
Improve the performance of the web application
The reason is that we can improve the performance of the application. If you think about it, each Observable we subscribe to is like creating an open connection that is never closed. As items are passed from the Observable to the Observer, next() and if defined, complete() methods are called. But they don’t close the connection. To learn more about Observable, go here.
If the Observable sends through four different items (messages from a backend server, for example), after each of these four messages, the next() handler is invoked. When the last of the four messages have been sent, the Observable calls the Observer’s complete() handler. However, the connection is still open, so if the Observable has another five messages to send, they can be sent to the Observer.
Methods for unsubscribing from Observable
There are a couple of ways we can unsubscribe from the connection the Observables make, as follows:
- Calling the
unsubscribe()method - Using the
takeUntil()operator from RxJs - Using
AsyncPipe
Call the unsubscribe() method
onInit life cycle
In the onInit handler, we make a call to the service and get some data. This returns an Observable because, as we will remember from looking at the HttpClient service, the get() method returns an Observable. We then set this Observable to a Subscription object, which is from RxJs. The reason we use this Subscription object is that this object has an unsubscribe() method.
onDestroy life cycle
In the onDestroy life cycle hook handler (which is run when a component is destroyed), we call the unsubscribe() method of the Subscription Object, which unhooks the connection that’s made to the Observable we set to the Subscription object, which in this case is the Observable that’s returned from the get() method.
Using the takeUntil() operator from RxJs
Here, we are still using the life cycle hooks, but we are also using the takeUntil() operator of RxJs (for further details of RxJs ). This takeUntil() operator keeps using a source Observable until the notifier Observable that we pass into the takeUntil() operator tells it to stop.
At the top of this demo component class, we create a new Observable called unsubscribe$ (the dollar sign is part of a naming convention that’s used when working with Observables). This Subject Observable is passed into the takeUntil() operator. Then, when it’s in the ngOnDestroy handler, the next() and complete() handlers of the unsubscribe$ Observables are called, which stops/unsubscribes the Observable being returned from the getSomeData() method. Basically, we are creating a new Observable that manages the first one.
Using AsyncPipe
The async pipe handles subscribing and unsubscribing for us. When this DemoComponent is destroyed, and the onDestroy() lifecycle hook that is part of all component is called (even if we don’t override it with our own version of the onDestroy hook), the async pipe will unsubscribe from the Observable.
As we can see, there are a variety of ways to unsubscribe from an Observable. What these three examples show is that libraries like RxJs help us manage Observables in our Angular applications. As we know, using Observables provides many advantages, but they do need to be managed. Using the methods we’ve just looked at, we can make use of Observables and still keep our applications performing well.
