"OnDestroy" is usefull for those who are using RxJS in imperative way. See "ngneat/until-destroy" library for more info.
In most cases Signals is a much better solution than plain RxJS in Angular. It's easy to learn, integrates well with Angular, performant out-of-the-box without any need for stupid RxJS hacks ("debounceTime(0)", "shareReplay()", "distinctUntilChanged()", etc), can be converted to RxJS Observable if you want to use RxJS operators.
Standalone Components is extremely nice feature, because it reduces boilerplate code, allows you to have a nicely structured tree of dependencies (unlike the "NgModules" way where people just throw everything in their bloated modules (especially "SharedModule")), allows you to clearly see what component depends on other components, allows you to have "standalone" directives and pipes without modules. In general, "NgModule" became a bloated mess over the years with 9 configs, out of which only 4 are actually used in most apps.
You can also lazy load standalone components by using "loadComponent" or "loadChildren" Route configs.
OnDestroy ref could be very useful to get rid of unsubscribe event emitters/subjects.
While there is a package called until destroy it will become pointless when angular will have it's own observable point of reference to know when a Component is destroyed. Simply - Less boilerplate
Signals are far easier to learn/understand/use and will be quicker to implement than let's say BehaviorSubject. At least that seems to be the idea.
For me standalone components are a lifesaver when it comes to largely reusable components. Something that would otherwise have to be stuck inside a shared module can now be it's own thing without the need to create a module.
And then there is the SCAM pattern that is pretty much replaced by standalone components.
I am a Systems Engineer and Fullstack Web Developer with over five years of experience working on various types of projects for companies of different sizes.
I am a Systems Engineer and Fullstack Web Developer with over five years of experience working on various types of projects for companies of different sizes.
OnDestroy ref could be very useful to get rid of unsubscribe event emitters/subjects.
While there is a package called until destroy it will become pointless when angular will have it's own observable point of reference to know when a Component is destroyed. Simply - Less boilerplate
Signals are far easier to learn/understand/use and will be quicker to implement than let's say BehaviorSubject. At least that seems to be the idea.
For me standalone components are a lifesaver when it comes to largely reusable components. Something that would otherwise have to be stuck inside a shared module can now be it's own thing without the need to create a module.
And then there is the SCAM pattern that is pretty much replaced by standalone components.
We are going to talk about it live next week on Twitter:
https://twitter.com/danielglejzner/status/1648622946464792577?s=46&t=O3K13poFxIpAs5QEGn_LLA
Make sure to join or listen to replay :)
You missed everything... watch a few youtube streams of ryan carniato explaining signals.
How can I join the war against React! I love angular angular is the future!
While Angular Team keep separate HTML, CSS and TS an each one in respective files, welcome the new changes that is expect to bring benefits.
You can have them in same file
I know, but I would not have see the angular Team take the decision like JSX
I would definitely not like TSX, but it's individual I guess. I like the clean interface between declarative and a component with an interface.
I've been working too much with React and the absolute mix of js and css and html is just killing me /s
Angular lost its identity since v5 :)
Super excited
As an Angular Developer, I'm waiting for this release & excited to see how it's going to be. 🔥
Angular FTW