Use takeUntilDestroyed to Unsubscribe from Angular's Observables

[@metric152]

Always killing the game. Thanks for another great video.

[@deborah_kurata]

Thank you so much!

[@ariensharma9859]

This content is truly remarkable! It is hard to believe that someone can explain such complex concepts with such ease.

[@etexalbania7301]

Thank you Deborah. When you have time please do a video for 2 dependent dropdowns using rxjs, like country for the first and capitals the second dropdown. All the best

[@deborah_kurata]

Thank you! Great suggestion! I'll add it to my list.

[@Wadih-bc]

You're awesome! Thanks a lot :)

[@CarlesNavedaPallares]

Thank you for creating and sharing such amazing content! Your clear and easy-to-understand explanations, even for complex concepts, are incredibly valuable and helpful. Keep up the fantastic work! 😊

[@deborah_kurata]

Wow! Thank you so much! 😊

[@andsons159]

Proud to watch this as the first person, I have a question how should one handle a case of "update list of users when backend updates them" must one use something like firebase fcm or can RxJs come to the rescue?

[@deborah_kurata]

😊 RxJS out of the box doesn't have features to support real-time messaging. SignalR, which uses WebSocket, is an option that returns an observable. Or you can use WebSocket directly. It looks like FCM may also support this scenario. I've not ever had this requirement in the applications I've built, so I don't have any experience with any of these options.

[@babutschi]

Very helpful! Thanks.

[@deborah_kurata]

Great to hear! 😊

[@CodingAbroad]

So I guess we can replace the normal takeUntil with takeUntilDestroyed?

[@deborah_kurata]

Yep.

[@CodingAbroad]

@@deborah_kurata thank you :) maybe a broad question but couldn’t we just use this for every single observable we need to subscribe to manually from now on? Or are there occasions where using takeUntilDestroyed is not ideal?

[@deborah_kurata]

@@CodingAbroad In my coding, I try to use toSignal whenever I can. Then the takeUntilDestroyed isn't needed. But if I can't use toSignal and have to manually subscribe, then I go with takeUntilDestroyed.

[@CodingAbroad]

@@deborah_kurata ah just seen your recent toSignal video to understand it better - thanks very helpful. Is it best practise to leave observables that are started using the template async pipe like this? advertisers$ = this.httpService.getCombinedData(); @if ((advertisers$ | async); as searchData) { } Or is there some signals magic I should be doing here too? I just want to list data out read only in this circumstance

[@deborah_kurata]

What you have still works. And at least as of now, there are no plans to deprecate the async pipe. But the Angular team is pushing forward with signals as the primary mechanism for displaying data from a component. At some future point, you could modify that observable (advertisers$) to a signal using `toSignal()`. Then display the signal in the template without the async pipe. advertisers = toSignal(this.httpService.getCombinedData()); @if (advertisers; as searchData) { } And you may not need the `as` clause, but it is still supported with signals.

[@graydhd8688]

Missed an opportunity to add "Unless it's my channel" to rule 1

[@deborah_kurata]

😄

[@richarddefortune1329]

Great video as usually.

[@deborah_kurata]

Thanks!

[@rkrao8582]

Hey Deborah, great content always. I have question here ! So what happens with CatchError returning EMPTY? Should I put takeUntilDestroyed before or after? I guess I didn't totally understand how teardown logic works.

[@deborah_kurata]

Thank you! Yes, you could modify the setError method to return EMPTY. You'd then want to change the code a bit because if there isn't a set of todos returned (even an empty set of todos), the current code implementation won't turn off the loading flag. I guess that provides an example of how being lazy (and not separately setting the loading flag off), can cause issues down the road. 😊 Regarding if it should be before or after takeUntilDestroyed ... in our example we use a switchMap and add the catchError in it's pipeline. That is the recommended approach.

[@Erril_Ferndal]

perfect, thats what i need! :)

[@deborah_kurata]

Great!