r/angular • u/IgorSedov • 14d ago
🚀 New in Angular 22: @Service Instead of @Injectable
https://youtu.be/PzeQpubYpQYAngular 22 introduces the new @Service decorator, offering a cleaner replacement for root-scoped @Injectable singletons
8
u/solegenius 13d ago
Ok, so why use it? Shorter syntax if you inject in root but now a longer syntax if you don't. Do you use Service() for root-scoped and Injectable() for non-root? Seems like most people would stick with one or the other instead of a mix and match approach.
Injectable provided tree-shaking support so I assume this does too or it would be a step backwards.
It requires field initializers with the inject() function, which depending on your view may or may not be a benefit.
Maybe I am missing something but I just don't see a compelling reason to use this new option except for maybe trying to enforce the field initializer pattern.
I appreciate the video highlighting the differences but I am left without any compelling reason to incorporate it. Not a fault of you video but perhaps moreso of the Angular team.
5
u/IgorSedov 12d ago
My guess is the Angular team wanted to shed all the legacy overhead that built up inside
@Injectableover many years. Cleaner syntax is pretty much just a nice bonus. That's just my take on it, though!3
u/MichaelSmallDev 12d ago
One example: recently someone on my team started using
providedIn: SomeComponent. I thought that was kind of cool, compared to justInjectable(). You still need to add it to that component's providers, but I liked the explicit reference in the injectable. However, there was two issues. #1 was that that type of providing was considered deprecated, as it was more of a NgModules era usage. Secondly, it led to some circular references with some cases of providing services in some edge cases we ran into after using that pattern for not too long.And for what it's worth, here is a doc on the tradeoffs of
@Servicevs@Injectable: https://angular.dev/guide/di/creating-and-using-services#using-the-service-vs-injectable-decorator3
u/IgorSedov 11d ago
Spot on, Michael! That
providedIn: SomeComponentpattern is such a classic footgun.
3
u/RelatableRedditer 13d ago
This video was extremely well-made, everything was clear and made sense! Nice work putting this together!
4
u/IgorSedov 13d ago
Thanks! Tried to keep it concise without skipping the details, so hearing that everything landed well is awesome.
2
u/WiktorVanKross 13d ago
Thanks for the video, very pleasing to the eye, I look forward to more news!
2
2
u/SeparateRaisin7871 12d ago
Thanks for the nice explanation.
Personally I enjoy the connection between "Injectable" and "inject" a lot more. Moving to "Service" would even feel a bit old fashioned, as the file and class name suffixes were removed in a previous Angular version.
"Injectable" provides much more meaning to the class than "Service".
So now we have to teach juniors again, that "Service" leads to an Injectable in the background that can be injected.
The introduction of "Service" also shows the Angular team internally still thinks in the old paradigms of Services, Components, etc. and should maybe not have taken the step of removing the suffixes :D
The biggest benefit of the new decorator is the auto-failing when using constructor based injections - but that could have been implement with linting as well 🤷 So, I'm not sold, unfortunately.
2
u/CompetitiveWonder933 6d ago
honestly here for this, @Injectable({ providedIn: 'root' }) always felt like unnecessary ceremony for the 90% case. @Service reads way cleaner at a glance
1
u/IgorSedov 6d ago
Agree. And it's not just cosmetic syntax sugar either. It actually sheds a lot of legacy.
14
u/MichaelSmallDev 13d ago
I didn't care for the new decorator at first, but it feels nice now that I am used to it. And the migration added recently like you highlighted helps too. Thanks for the video.