The new DestroyRef Provider in Angular 16 (2023)
Вставка
- Опубліковано 22 чер 2024
- 💥 Become a PRO with my in-depth Angular Forms Course💥
🔗 10% discount for the first 10 students - bit.ly/advanced-ng-forms-disc...
The Angular 16 is out which brings a myriad of new cool features and one of such features is a new injectable entity called DestroyRef that you can inject into any Angular building block like component or service and register a callback that will be executed when this scope is destroyed. Sounds like the ngOnDestroy lifecycle hook, right? Exactly! In this video, we will try to figure out what is the difference between those 2 options and which additional options give us the brand-new DestroyRef token.
🕒 Time Codes:
00:00:00 - Intro;
00:01:11 - Basic use cases and differences with ngOnDestroy hook;
00:07:25 - How it is used in takeUntilDestroyed;
00:11:18 - Outro;
💡 Short Frontend Snacks (Tips) every week here:
Twitter - / decodedfrontend
Instagram - / decodedfrontend
LinkedIn - / dmezhenskyi
💡 Short Frontend Snacks (Tips) every week here:
Twitter - twitter.com/DecodedFrontend
Instagram - instagram.com/decodedfrontend
LinkedIn - www.linkedin.com/in/dmezhenskyi
0:33 that was exact my reaction :D
Another great video, you never fail to surprise me with your content. You're becoming the "source of truth" in the Angular world.
Thanks so much. You continue uploading great tutorial videos. You always give a clear explanation of the abstract concept. Your pronunciation becomes far better than one year ago. Congrats
I am glad to hear that! Thank you for the feedback 😊
Very cool new features.
Thanks for a great lesseon @Dmytro.
Thanks for giving us the context on the use case of the DestroyRef, cant wait to push our company projects to Angular v16 to try this staff
Great video as always 👍🏼
nice indepth explanation, thank you. keep it up
I should definitely add this video into favourites. Too much useful information for me. Especially considering that our project gonna be updated to Angular v16
Thank you! Glad you like it :)
good approach thanks you for your examples
Thank you for this video!
Thank you for this comment :)
time to drop some 3rd libs, thank you for sharing
Thanks
Thank you for your support! I appreciate it soo much :)
As always tons of awesome info and as always I learned something completely not relevant to this topic. Didn't know we can call baseComponent's method by using super....
I think this is the problem for many self learners - sometimes we just miss something completely
Thank you! I am glad you like it :)
Merci!
Wow, thank you so much for your support 🙏 it is invaluable 😊
takeUntilDestroyed is something we really needed to remove a lot of boilerplate code :D
Nice feature. And a useful one. Also a great explanation! I have a question though: I was taught to use "subscription.add(observable)" and then call "subscription.unsubscribe()" in ngOnDestroy. That is all instead of "takeUntill" pattern. Is there a difference between those two? If so then what is it and why use one over the other?
Hey, not Dymtro here but here is my 2 cents. So takeUntil can be used even in instances where you do not want to destroy the component specifically.
Last time I did so was when I was refreshing a page by button clicks. So when I click the refresh button the system had to stop all running http calls to the backend and restart again. So on the forkJoin making the calls I piped the takeUntil such that when I click the button, the subject emits first then calls cancel and then I would run the fetches again.
In short, takeUntil allows you to destroy observables even without destroying the component
That intro 😂 good explanation thanks
Thanks :)
Will certainly experiment with this later today, but do you already know if destroyref can be used inside any class (non angular decorated class, not a component, nor directive, etc.) like i e. a User class, to perform clean up logic when the class instance is destroyed?
As far as I know it won't work with a regular class. You would need to annotate it with @Injectable() because otherwise you won't be able to inject into this class anything (including the DestroyRef)
@@DecodedFrontend Thanks. Haven't tried myself yet, but I bet you are right. I'm using classes that extends FormGroups or FormArray to encapsulate business logic in it. Sometimes I have to subscribe to observables inside the class, thus I have the problem of manually unsubscribing from outside the class when a control is removed from the form... Do you think decorating them as @Injectable could lead to performance issues? I might have several of these controls in a single form.
Which is better to use: takeUntilDestroyed() or DestroyRef, and why?
Thanks for another useful video, Dmytro and especially for Khaby Lame part)
Thank you, Gagik! ;)
how does destroyRef understands when to destroy? For example, at the 4:58, we use it as outter function but it somehow understands when our component destroyed
it is because inject() function is called in context of component and tries to resolve the "closest" provider for DestroyRef token which comes from component injector, so it gets the reference to the DestroyRef accosiated with this component.
i have a question and it is not about this video.
- how can i make @angular/core package local in my angular project and use it as a local package in my project? , so that i can discover more in it also work on it
How to open rxjs operators implementation code ?
Hey, is it reasonable to move to Angular 16, Do all libraries support Angular 16
Why don't we need to put DestroyRef in providers array?
Angular resolves it automatically under the hood, so you don't have to provide it manually each time. The same is true for ViewContainerRef, ElementRef, and some other tokens.
idk what they are trying to do with this feature though to be honest,
reducing boilerplate ?
the custom function .onDestroy for this reference feature is unnecessarily complex to be frank
hope they dont remove onDestroy lifecycle hook
i don't mind adding a boiler plate for subject and function
Maybe I'm missing something, but this feels terrible. It's basically inheritance in disguise and now mandates angular for even simple object creation due to injection coupling.
It's is a good "native" replacement for www.npmjs.com/package/@ngneat/until-destroy
Looking forward to replace it once our project migrates to v16
Exactly :)