Hi welcome back. In this video I'm going to share with you my personal rating of the top 6 mistakes that developers do in RxJS code. This video is focused more for beginners with Angular, but I think even more experienced developers can learn something new from it. If it is your first time on my channel, my name is Dmytro Mezhenskyi and my goal is to help you to become Advanced Angular developer. Who develops Angular applications consciously knowing what you're doing and why. In the past I created quite a lot of advanced and unique tutorials about Angular of course and you can check them out later but now let's focus on RxJS and the mistakes that we, time after time, see in our code base. All right for this tutorial I prepared a demo component the code of which is actually full of bad practices and mistakes, but before we start to explore and fix them all let me very quickly introduce an application and provide more context about its implementation. So the application mostly consists of one single component the user search component which allows me to find users by typing their names eventually the users I find will be displayed there below. We can also define how many results I want to see per page and I can do that by selecting the corresponding value from the dropdown. Okay what about the implementation the implementation is indeed very simple in the template I have a small reactive form that contains the text input and the select element and the value of this form is going to be the search configuration that will be used to configure the HTTP call in the code it looks like the following you can see that I created an observable searchConfig starting from the form value changes so when the user changes any of these form controls the new config object is emitted. Then I subscribe to the searchConfig observable in order to get config object and provide this object to the findUsers() method as an argument which performs under the hood the HTTP call to the server with the parameters defined in the searchConfig then I subscribe to the observable that this method returns in order to kick off the HTTP call once data is received I get it inside the subscribe callback and assign it to the class property so that I can use this data in the component template to display their corresponding information. So this is how it is currently implemented, implemented terribly implemented wrongly, but this is what I see very often reviewing the projects of my clients now let's see what is wrong with this code . And the mistake number one is nested subscriptions you know when it comes to the software development I'm a kind of person who tries to avoid such a strong words like never or always, but this is one of those rare cases where I can undoubtedly say please never do this. Despite it looking ugly and messy by subscribing to the high order observable you lose their reactive context for a while, then you probably perform some imperative logic in between and again you enter the reactive context in the nested observable and this opens a lot of space for different kinds of mistakes and errors and this is not how you are supposed to work with RxJs. In RxJs you should try to keep your data within the reactive context as long as possible and resolve data at the very last moment. So how could we make this part better, in scenarios like this you should always use the RxJs flattening operators. The most popular one is the switchMap() operator which you can apply in the pipe() method of the high order observable. This operator requires a callback function the argument of which one has a value emitted by the high order observable. The return value of the callback has to be en nested observable which is in my case the one that defined users method returns. The switchMap() will under the hood, subscribe to this nested observable kicking off the HTTP call. And the data returned from the server will go to the subscribe callback of the high order observable. So now I just have to clean up my code a little right here and I will get the same result actually as I had before, but now it is cleaner, it is safer and more predictable, and another cool thing that the switchMap() operator does is that if a new search config arrives while the current HTTP call is pending, the switchMap() will cancel the pending call and schedule the new one with the new search configuration and if you want to learn more about flattening operators in RxJS, and how they differ from each other I have a series of videos where I cover exactly those operators and you can check this video out following the hint that should appear right there above. But now let's move forward to another mistake and the mistake number two, it's a wrong usage of the takeUntil() or takeUntilDestroyed() operators for unsubscription management. Using these operators can give you a false sense of confidence that you successfully prevented memory leaks, for example in my case everything looks safe, because I use the takeUntilDestroyed() operator, which is supposed to handle on subscription when the component is destroyed, right? However approaches based on the takeUntil() operator they handle on subscription only for the operators located before the takeUntil() and they have no effect on the downstream subscriptions so if the component is destroyed while the HTTP call is pending it will not be cancelled which is not necessarily a big issue for a single HTTP call but if you have a long living subscription something like websocket connection there, then you might get a problem. So long story short if you choose to handle unsubscription using strategy based on the take and until operator then make sure that you move this operator to the end of the pipe operator chain, also you can set up a dedicated Eslint rule in your project to ensure that neither you or your colleagues will make this mistake in the future. If you want to get more details about exactly this use case you can check out my another video about exactly this topic again there will appear the hint and now let's move to the next mistake. And mistake number three it's a manual subscription in components, but before a short disclaimer I'm not saying that you should never subscribe manually it is not true true uh sometimes we cannot avoid manual subscriptions for example, in directives or in services. My point is that in components we have much better options to deliver data from observables to the component view. For example in my case I could simply remove the manual subscription like that and the observable itself I can assign to some property in the component and from here I have already two options if you use signals in your application you could convert the observable to a signal using the toSignal() helper function, and I would say that in the modern Angular, it would be a preferable way to do but if you use the older angular version or if for whatever reason you don't use signals in your app you can always use the good old async pipe for that you just have to import the async pipe in the component Imports array, and then whenever you need in a template, you can apply the async pipe to the observable you actually need. In my case it is users observable, so I can do it just like that. the cool thing about any of these two approaches is that besides automatic subscription to the observable, they also perform automatic unsubscription when the corresponding view is destroyed. This means that I can simplify my users observable even more by removing that takeUntilDestroyed() operator along with the destroy ref token by the way if you are curious what is destroyRef token and why it exists in Angular again I have a dedicated video about that you can check this out and yes in this tutorial there will be quite a lot of references to my other videos but nevertheless let's move forward and talk about another mistake that we recently introduced during this last refactoring. And mistake number four it's executing observable logic more times than we need, terrible title, but I couldn't come up with anything better, in short the problem is the following if I change the search config I always see two identical HTTP calls in the console. This is something new because we didn't have this be behavior before and the trick here is that actually, each new subscription to the observable triggers the execution of the whole operator pipe chain and the creation of the value producer for each subscriber. For this kind of behavior we have a special term 'Cold observable' and this is exactly my case as you remember I applied two times the async pipe to the users observable so I created two subscriptions, two subscriptions means that two times will be executed the observable logic, which leads to two HTTP calls, simple and again there are a couple of ways how to fix it. First approach is the wrapping the code with the 'if' block subscribe to the observable there only once, and then assign the result from this observable to the template variable that you can use within this blog. Alternatively you can use special operators that make your observable hot making them share the latest observable value with new subscribers. You can achieve that using a group of operators like share() or shareReplay() and others, but in my opinion shareReplay() is the most popular and universal one, and the idea here is to define how many value emissions from the RxJs stream have to be replied to new subscribers. Since I need only latest value from the observable I define one, as an argument so now when the new subscriber arrives the logic before shareReplay() will not be executed. Instead shareReplay() will just return the latest value that was emitted to the stream. So now if we say this change and try to find any other user once again, you can see that now I don't have duplicated HTTP call which is exactly what I expected, but let's move forward to mistake number five. And mistake number five it is improper usage of the distinctUntilChanged() operator. To demonstrate this issue I would like to expand the searchConfig$ observable and let me very quickly break it down. Here you can see the usage of the debounceTime() operator with the value of 300 milliseconds. I needed to filter out rapid successive emissions to the stream allowing only the final value to be emitted after the specified 300 milliseconds delay. In such a way I can reduce the number of HTTP calls and the server load. However it means that the user can change the searchConfig and revert it back within 300 milliseconds emitting the same config again and it will cause the same HTTP call. This is exactly what the distinctUntilChanged() operator should prevent, but as you can see it doesn't do its job. The thing is that in this configuration the distinctUntilChanged() operator works properly only with primitive data like strings, boolean, numbers, etc. But here the stream emits objects, and to compare if the object has changed it uses strict comparison, however if you compare two objects like this, you will always get false, although the shape of the object is the same, that's why if you emit non-primitive data types in your observable and you use the distinctUntilChanged() operator there you have to use a predicate function that allows you to compare previous and current values more accurately by comparing values of certain object keys or make the deep object comparison. And by the way Pro Tip if you need to track only one object key you can shorten this notation by using another operator called distinctUntilKeyChanged() and then you just provide as a value the name of the key you want to track so now let's save our changes and try to reproduce their previous behavior again. And you can see that this time the HTTP call with the same search config has not been performed which is actually cool as you can see knowledge about fundamental data structures and their differences is quite important in software development and if you would like to learn more about data structures algorithms and computer science, check out platform called brilliant which is sponsor of today's video what is special about brilliant is that there you can find thousands of interactive lessons and courses in computer science, data analysis, programming and of course AI so there you can learn not only computer science and math fundamentals but also algorithmic thinking and new programming languages like for example python, learning on brilliant is really easy and engaging because of the Hands-On approach which helps you deeply understand Concepts to try everything brilliant has to offer for free for a full 30 days check the video description where you can find a special link brilliant.org/decodedfrontend click on it and you will also get 20% off for the annual premium subscription and now let's get back to the video. And the last mistake, mistake number six it is a per forming side effects in the wrong place. In short, side effect is when a function interacts and modifies anything outside of its scope. This might make your code potentially harder to understand harder to test and harder to debug. Despite that, we cannot avoid side effects completely because it is simply impossible for example here in the map() operator besides reshaping the config object I save also the config in the localStorage this is a side effect, but I cannot avoid it because it is part of my functionality. The problem here is not the side effect itself, but more the fact that looking at the code of this observable I have no idea if it performs side effect or not, and if yes then what exactly will be effective, which component properties will be modified and so on. That's why in RxJS operators you have to use pure functions means the functions that don't perform side effects, and if you need to perform them you have to do it inside the special operator called tap(). This is exactly what this operator is designed for so in my case, the interaction with the localStorage has to happen right there. So now I can immediately see that the observable has side effects and I can go and see what exactly happens there which makes my code more clear and predictable. All right guys thanks for watching, I hope this video was useful and it will help you to improve the code quality in your angular projects. What would be your personal rating or the top let's say five mistakes that you see people do in RxJS code, it would be be very interesting, please share this in the comment section under this video. Otherwise if you would like to support my channel please share this video with your colleagues and friends, in your social media profiles, and check out my Advanced Angular video courses they can really help you to bring your angular skills to a next level. Otherwise guys I wish you productive week ahead stay safe, and see you in the next video.