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
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
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
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
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
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.
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
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.
![KSI - Thick Of It (feat. Trippie Redd) [Official Music Video]](http://i.ytimg.com/vi/At8v_Yc044Y/mqdefault.jpg)
![OsamaSon - ik what you did last summer [Official Music Video]](http://i.ytimg.com/vi/4DIQDnu3mr4/mqdefault.jpg)
💡 Short Frontend Snacks (Tips) every week here:
Twitter - twitter.com/DecodedFrontend
Instagram - instagram.com/decodedfrontend
LinkedIn - www.linkedin.com/in/dmezhenskyi
Another great video, you never fail to surprise me with your content. You're becoming the "source of truth" in the Angular world.
0:33 that was exact my reaction :D
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 😊
Great video. clear everything now
takeUntilDestroyed is something we really needed to remove a lot of boilerplate code :D
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
nice indepth explanation, thank you. keep it up
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 :)
good approach thanks you for your examples
Thanks
Thank you for your support! I appreciate it soo much :)
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 :)
Very cool new features.
Great video as always 👍🏼
Thank you for this video!
Thank you for this comment :)
Merci!
Wow, thank you so much for your support 🙏 it is invaluable 😊
time to drop some 3rd libs, thank you for sharing
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
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?
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.
That intro 😂 good explanation thanks
Thanks :)
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
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.
How to open rxjs operators implementation code ?
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
Hey, is it reasonable to move to Angular 16, Do all libraries support Angular 16
Thanks for another useful video, Dmytro and especially for Khaby Lame part)
Thank you, Gagik! ;)
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 :)