TOP 6 Mistakes in RxJS code

Summary

In this informative video, Dmytro Mezhenskyi identifies and explains the top six common mistakes developers make when working with RxJS in Angular applications. He provides practical solutions for issues like nested subscriptions, improper unsubscription management, manual subscriptions in components, unnecessary HTTP calls, incorrect use of the distinctUntilChanged() operator, and performing side effects in the wrong place. The tutorial offers insights to help developers write cleaner, safer, and more predictable RxJS code.

Takeaways

• 📝 The video discusses common mistakes made by developers in RxJS, particularly for those working with Angular, and aims to educate on better practices.
• 🔍 The speaker, Dmytro Mezhenskyi, introduces a demo component with bad practices to demonstrate and correct common RxJS mistakes.
• 🙅‍♂️ Nested subscriptions are discouraged as they break the reactive context and can lead to errors; RxJS operators like 'switchMap()' should be used instead.
• 🛑 Misuse of 'takeUntil()' or 'takeUntilDestroyed()' for unsubscription can lead to memory leaks; these operators should be placed at the end of the pipe chain.
• 🔄 Avoid manual subscription in components when possible; use 'async pipe' or 'toSignal()' for automatic subscription and unsubscription.
• 🔄 'Cold observables' can lead to unnecessary HTTP calls; use operators like 'shareReplay()' to make observables 'hot' and share values with new subscribers.
• 🔄 The 'distinctUntilChanged()' operator requires careful use, especially with non-primitive data types, to ensure accurate comparison of object changes.
• 🛠 Side effects, such as modifying external state, should be performed within the 'tap()' operator for clarity and predictability in code.
• 🚀 The importance of understanding data structures and their differences is highlighted for effective software development with RxJS.
• 🎓 The video also promotes learning computer science fundamentals and algorithmic thinking through the platform 'brilliant.org'.
• 💻 The speaker encourages viewers to improve code quality in Angular projects and to share their insights on common RxJS mistakes in the comments.

Q & A

What is the main focus of the video?

The video focuses on discussing the top 6 mistakes developers make in RxJS code, particularly for beginners with Angular, but also beneficial for more experienced developers.

Who is the presenter of the video?

The presenter is Dmytro Mezhenskyi, who aims to help viewers become advanced Angular developers.

What is the context of the demo component used in the video?

The demo component is a user search component that allows users to find users by typing their names and displays the results. It also includes a dropdown to define the number of results per page.

What is the first mistake discussed in the video?

The first mistake discussed is nested subscriptions, which the presenter strongly advises against due to the potential for errors and loss of reactive context.

What is an alternative to nested subscriptions in RxJS?

An alternative to nested subscriptions is the use of RxJS flattening operators, such as switchMap(), which helps maintain the reactive context and avoid nested subscriptions.

What is the issue with using takeUntil() or takeUntilDestroyed() for unsubscription management?

The issue is that these operators only handle unsubscription for operators located before them in the chain and have no effect on downstream subscriptions, potentially leading to memory leaks.

What is the recommended approach to handle unsubscription using takeUntil() or takeUntilDestroyed()?

The recommended approach is to move the takeUntil() or takeUntilDestroyed() operator to the end of the pipe operator chain to ensure proper unsubscription management.

Why should manual subscriptions in components be avoided?

Manual subscriptions in components should be avoided because there are better options available, such as assigning the observable to a component property and using async pipe or toSignal() for automatic subscription and unsubscription.

What is the problem with executing observable logic more times than needed?

Executing observable logic more times than needed can lead to duplicated HTTP calls or unnecessary processing, which can be avoided by using techniques like wrapping the subscription in an 'if' block or using operators like shareReplay().

What is the issue with using distinctUntilChanged() with non-primitive data types?

The issue is that distinctUntilChanged() uses strict comparison for non-primitive data types, which always returns false even if the object shapes are the same, thus not preventing duplicate HTTP calls as expected.

What is the recommended way to compare non-primitive data types in observables?

For non-primitive data types, a predicate function should be used with distinctUntilChanged() to compare specific object keys or perform a deep object comparison accurately.

Why is it important to perform side effects in the correct place?

Performing side effects in the correct place, such as within the tap() operator, makes the code clearer and more predictable, as it explicitly shows where and how side effects are being performed.

What is the purpose of the tap() operator in RxJS?

The tap() operator is designed for performing side effects, allowing developers to interact with external scopes or modify component properties in a clear and predictable manner.

What is the final mistake discussed in the video?

The final mistake discussed is performing side effects in the wrong place, which can make the code harder to understand, test, and debug.

What platform is recommended for learning computer science, data analysis, and programming?

The platform recommended is Brilliant, which offers thousands of interactive lessons and courses in computer science, data analysis, programming, and AI.

What special offer is available for new users of Brilliant mentioned in the video?

New users can try Brilliant for free for a full 30 days, and there is a 20% discount on the annual premium subscription using a special link provided in the video description.

Outlines

00:00

📚 Introduction to Common RxJS Mistakes in Angular

The video script begins with an introduction by Dmytro Mezhenskyi, who aims to guide viewers to become advanced Angular developers with a clear understanding of their code. He sets the stage for a tutorial focusing on the top 6 mistakes often seen in RxJS code, particularly among Angular beginners but also relevant for more experienced developers. The script mentions a demo component filled with bad practices as a basis for the discussion. The application context is a user search component with form controls for user input and pagination settings, which triggers HTTP calls based on the search configuration.

05:07

❌ Nested Subscriptions and the RxJS Reactive Context

The first mistake discussed is the use of nested subscriptions in RxJS, which Dmytro strongly advises against due to its potential to cause errors and disrupt the reactive flow. He explains that the correct approach is to use RxJS flattening operators, such as 'switchMap()', to maintain the reactive context and avoid nested subscriptions. The 'switchMap()' operator is introduced as a way to handle HTTP calls reactively, cancelling pending requests when new search configurations are submitted, thus improving code cleanliness and predictability.

10:08

🔄 Misuse of Unsubscription Operators in RxJS

The second mistake highlighted is the incorrect use of 'takeUntil()' or 'takeUntilDestroyed()' operators for managing unsubscriptions. Dmytro clarifies that these operators only handle unsubscriptions for operators preceding them in the chain and do not affect downstream subscriptions. He advises moving these operators to the end of the pipe chain and setting up ESLint rules to prevent such mistakes. The discussion also touches on the importance of proper unsubscription management to prevent memory leaks, especially in long-lived subscriptions like websocket connections.

15:13

🔧 Avoiding Manual Subscriptions in Angular Components

The third mistake involves manual subscription in components, which Dmytro argues can be avoided in favor of more declarative approaches. He suggests removing manual subscriptions and using either the 'toSignal()' helper function for signal-based state management or the 'async' pipe for automatic subscription and unsubscription. This not only simplifies the code but also ensures that subscriptions are managed automatically when the component view is destroyed, thus preventing memory leaks.

🔄 Executing Observable Logic Efficiently

The fourth mistake discussed is the unnecessary execution of observable logic multiple times due to 'cold observables'. Dmytro explains that each new subscription triggers the entire operator pipeline, leading to duplicate HTTP calls when not intended. To resolve this, he suggests using 'if' blocks to control subscriptions or employing operators like 'share()' or 'shareReplay()' to make observables 'hot', ensuring that only the latest value is shared with new subscribers, thus eliminating duplicate HTTP calls.

🔄 Improper Use of the distinctUntilChanged() Operator

The fifth mistake is the improper use of the 'distinctUntilChanged()' operator when dealing with non-primitive data types. Dmytro points out that this operator only works correctly with primitive data and that for objects, a predicate function or 'distinctUntilKeyChanged()' is needed for accurate comparison. He demonstrates how to use these operators to prevent duplicate HTTP calls caused by rapid successive emissions of the same config object within a debounced stream.

🛠️ Side Effects in RxJS and the tap() Operator

The final mistake discussed is performing side effects in the wrong place within RxJS observables. Dmytro explains that side effects, such as modifying external state, can make code harder to understand, test, and debug. He emphasizes the importance of using pure functions in RxJS operators and reserving side effects for the 'tap()' operator. This practice clarifies the presence of side effects and makes the code more predictable and maintainable.

Keywords

💡RxJS

RxJS, short for Reactive Extensions for JavaScript, is a library for reactive programming using Observables, which makes it easier to compose asynchronous or callback-based code. In the context of the video, RxJS is a core library used in Angular applications for managing and composing asynchronous data streams. The video discusses common mistakes developers make when using RxJS in their Angular code.

💡Nested Subscriptions

Nested subscriptions refer to the practice of subscribing to an Observable within another Observable's subscription. This can lead to complex and hard-to-maintain code. The video emphasizes that nested subscriptions should be avoided in RxJS, as they can cause various errors and are not in line with the reactive programming paradigm.

💡switchMap()

The switchMap() operator in RxJS is a flattening operator that allows you to cancel the previous inner Observable when a new value is emitted. It is used to ensure that only the latest HTTP call is made when new search configurations are provided, as shown in the video. This operator helps in creating a cleaner and more efficient code by preventing unnecessary HTTP calls.

💡takeUntil() / takeUntilDestroyed()

The takeUntil() and takeUntilDestroyed() operators in RxJS are used for unsubscription management to prevent memory leaks. However, as the video explains, they only handle unsubscription for operators located before them and do not affect downstream subscriptions. Proper use of these operators is crucial to ensure that subscriptions are correctly canceled when components are destroyed.

💡Manual Subscription

Manual subscription in Angular components refers to explicitly subscribing to an Observable within the component's code. The video suggests that this practice is not recommended in components, as Angular provides better options like the async pipe or using signals, which also handle automatic unsubscription when the component is destroyed.

💡Async Pipe

The async pipe in Angular is a built-in pipe that subscribes to an Observable or Promise and automatically handles unsubscription when the component is destroyed. The video demonstrates that using the async pipe can simplify the code by removing the need for manual subscriptions and handling of unsubscriptions.

💡Cold Observable

A cold Observable is one where each new subscription triggers the execution of the entire Observable logic, creating a new value producer for each subscriber. In the video, the issue of executing Observable logic multiple times due to multiple subscriptions is discussed, and solutions like using shareReplay() to make the Observable hot are suggested.

💡shareReplay()

The shareReplay() operator in RxJS is used to make an Observable hot, meaning it shares the latest emitted values with new subscribers. In the video, shareReplay(1) is used to ensure that only the latest value is emitted to new subscribers, preventing duplicate HTTP calls when the search configuration changes.

💡distinctUntilChanged()

The distinctUntilChanged() operator in RxJS is used to filter out consecutive, duplicate values from an Observable stream. The video points out that this operator works only with primitive data types by default. For non-primitive types, such as objects, a predicate function or the distinctUntilKeyChanged() operator is needed for accurate comparison.

💡distinctUntilKeyChanged()

The distinctUntilKeyChanged() operator is a variation of distinctUntilChanged() that allows for comparison based on a specific object key. This is useful when you only need to track changes in a particular key of an object, as shown in the video, where it is used to prevent unnecessary HTTP calls when the same search configuration is emitted.

💡Side Effects

Side effects in programming refer to actions that modify something outside the scope of the function they are in. In the video, the map() operator is used to demonstrate side effects, such as saving the search configuration to localStorage. The video advises using the tap() operator for side effects to make the code clearer and more predictable.

💡tap()

The tap() operator in RxJS is designed for performing side effects within an Observable chain. It allows you to interact with and modify external state without affecting the data stream. The video recommends using tap() to make side effects explicit and the code easier to understand and debug.

Highlights

Personal rating of the top 6 mistakes in RxJS code for beginners and experienced developers.

Introduction to the demo component showcasing common bad practices in RxJS.

Explanation of the user search component and its functionality.

Critique of the initial implementation of the search feature with nested subscriptions.

Advocacy against nested subscriptions in RxJS for maintaining reactive context.

Introduction of the switchMap() operator for handling nested subscriptions.

Demonstration of improving code with switchMap() for cleaner and safer RxJS operations.

Discussion on the misuse of takeUntil() or takeUntilDestroyed() for unsubscription management.

Clarification on the proper placement of takeUntil() operators for effective unsubscription.

Warning against manual subscription in components and suggesting better alternatives.

Recommendation to use async pipe or toSignal() for automatic subscription and unsubscription.

Identification of the issue with executing observable logic more times than necessary.

Solution to prevent duplicate HTTP calls using shareReplay() or similar operators.

Improper usage of distinctUntilChanged() operator with non-primitive data types.

Use of distinctUntilKeyChanged() for tracking changes in a specific object key.

Importance of understanding data structures for effective RxJS development.

Mistake of performing side effects in the wrong place and its impact on code clarity.

Recommendation to use tap() operator for side effects to improve code readability.

Invitation for viewers to share their top RxJS mistakes and to support the channel.

Transcripts

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.