Use takeUntilDestroyed to Unsubscribe from Angular's Observables

Рет қаралды 5,839

Deborah Kurata

Күн бұрын

Пікірлер

@metric152 6 ай бұрын

Always killing the game. Thanks for another great video.

@deborah_kurata 6 ай бұрын

Thank you so much!

@ariensharma9859 3 ай бұрын

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

@deborah_kurata 2 ай бұрын

Thank you so much! I'd always wanted to be a teacher ... so I'm channeling my inner teacher with these videos. 😊

@etexalbania7301 6 ай бұрын

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 6 ай бұрын

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

@CarlesNavedaPallares 6 ай бұрын

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 6 ай бұрын

Wow! Thank you so much! 😊

@andsons159 6 ай бұрын

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 6 ай бұрын

😊 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.

@graydhd8688 3 ай бұрын

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

@deborah_kurata 3 ай бұрын

😄

@CodingAbroad 6 ай бұрын

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

@deborah_kurata 6 ай бұрын

Yep.

@CodingAbroad 6 ай бұрын

@@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 6 ай бұрын

@@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 6 ай бұрын

@@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 6 ай бұрын

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.

@richarddefortune1329 6 ай бұрын

Great video as usually.

@deborah_kurata 6 ай бұрын

Thanks!

@babutschi 5 ай бұрын

Very helpful! Thanks.

@deborah_kurata 5 ай бұрын

Great to hear! 😊

@rkrao8582 6 ай бұрын

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 6 ай бұрын

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.