It is not really difficult to follow that rule. Otherwise, your code would leak, leading to unexpected behavior. It will handle unsubscription for you.Īny time you subscribe to an Observable, you need to unsubscribe. It has two main advantages compared to sending data directly through component properties. The async pipe is a feature provided by Angular to handle asynchronous data in the Angular template. With the reactive approach, we are directly using the Observable with the async pipe on the template. With the imperative approach, we are using the component variables to display the data on the template. It would honestly be a shame to try to reimplement some of those features manually just because you decided not to declare an Observable. There is a lot that is already built in the RxJS library. It comes with advanced features, built-in.ĭebouncing, caching, and much more. Pure functions are just easier to test in general. Side effects can lead to more complex debugging because you never know exactly where the change happened. Each time you are using component properties in a function, this function is no longer pure, and you are creating a side effect. It is very convenient, on the developer side, compared to the reactive approach. But sometimes, once you have this variable created, you can be tempted to use it elsewhere in the component. In this example, I only use those variables inside that function. With the imperative approach, you have to use component properties. It makes **testing **and **debugging **easier. Just by looking at it, try to imagine how it would be with three nested subscribes, each one having a specific error management bloc. The nested subscribe is also something that increases complexity. Moreover, you have to add some code to push the subscription to a list for unsubscribing later, making the code heavier. A bloc of imperative code will always require you to dive into it to attempt to understand what was the goal of the bloc. It increases readability.Ī sequence of operators is pretty straightforward to read and understand (given that you know the most common RxJS operators). In my opinion, there are some advantages to using the reactive instead of the imperative approach here. I then do the same type of processing as previously but this time, everything is stored in the Observable instead of an object. For that reason, I used the ViewChild decorator to get the Observable from the HTML element. Everything gets triggered each time the input changes on the template.įor the reactive version, it is better to start the process from an Observable instead of a callback method. To illustrate this first reason, let's have a look at the way I handled the API call in both versions of the application.įor the imperative version of the application, I simply subscribed to both endpoints, processed and stored the data into component properties that I then displayed on the page. Reason #1: you are not using RxJS operators as much as you could The code is available on my GitHub with an imperative and a reactive branch, so you can compare. I used the weather API to get the weather data. You just type the name of a city and then get the weather for the next couple of days in that location. Imperative vs ReactiveĪs I usually do with those articles, I built an elementary application using the two different approaches. Thus, you are not making an optimal use of RxJS or Angular features. It triggers the call and handles the result.Ĭoming back to the main topic of the article, if you are writing a lot of logic inside the subscribe callback, you are using an Observable as if it was a Promise. Whereas with a Promise, when you call the then function, you are actually doing both operations at once. In other words, making the call and handling the results are separated operations. You can declare how your data should be handled once received, but you will then need to explicitly subscribe to trigger the asynchronous call. The key difference between an Observable and a Promise is that Observables are lazy. As with a regular JavaScript Promise, the goal of an Observable is to handle asynchronous events. What is the subscribe callback in Angular?Īn Observable is the main tool provided by the RxJS library whose Angular uses extensively. This article will be very opinionated, so comments or questions are more than welcome. As Angular developers, we really should be doing the same. Angular embraces RxJS and the reactive programming paradigm. I have always considered this to be a bad practice. Quite frequently, I encounter a big block of imperative code inside a subscribecallback. Angular 14 RxJS Example to Create Observables With Error Handling & Events in TypeScript
0 Comments
Leave a Reply. |