Why I decided to switch to the inject() function in Angular

for the longest time i used the constructor DI and inheritance but i realized sooner than later with new requirements it makes a hell of editing cycle so i switched to the inject() but using some backdoor way that allows injecting in ngoninit and so on by making custom AppInjector that gets injected in AppModule, that way it will be available to use whenever you need instead of constructor context too.
I don't understand perfectly why angular team didn't include this approach to be in their default injector, mostly something that has to do with lazy loaded modules/services and TreeShaking builds yet i find it very solid for most use cases.

SO in short HELL YES I AM WITH THE inject(service); to hell with constructor injection unless if you are forced to for some reason.

Or to be reasonable a mix and match might make sense in some cases when you need to make sure that who ever is extending your class knows it's a must to have these services. lot's of other frameworks stayed on the constructor injection and i do believe it's one of the reasons for that.

thank you for th calrification. Just one thing. how do we use the services inside spec for testing?

A better option would be to use annotations. Like @Autowired in spring.

Omg you just solved my over years issue with components inheritance 😬 i tended to create nested sub properties like _ _ _ appService to get it somehow working cause I could not find any other alternative

Makes usage with the occasional, unavoidable inheritance much nicer.

huhu I've got a question and would love if someone could answer. So I do prefer using the inject function, but I run into the following problem: I mostly want to have the injected Services private as there is no need for accessing them outside of the component. And I mostly want to use the declerative approach and make my members constants. So it would look like this:

public readonly someObservable$ = someService.doSomething$();
private readonly someService = inject(someService);

this code obviously fails as I use the service before I declare it. But if I move the service up, then I have the problem with eslint and member ordering; it says that private members are to be declared after the public ones. I wonder, how can we fix this problem? I can of course just ignore the tslint rule for this case but is this the best practice?

That adding removing in baseclass could break on runtime than compile time like constructor injection

If you don't need the dependencies / different instances, use abstract class.

What about for unit testing?

I switched to inject and I love it, no regrets at all! :)

How about 'private' constructor injections? Can the inject() approach replace the those? Like. Is a private variable deceleration for an inject(service) as private as when declared private in a constructor injection?

and testing? is more more complicated

Great video, as usual :)

This is so neat. I don't know why Angular doesn't mention it as an option in the Dependency Injection documentation page.

Ha, really eager to see your faces when you find out in React, there is no such thing as injection or constructors. You can import anything from anywhere and just have it working.
Through the comments I see many people view an inject function as a Biblical sin and is a path to damnation. Grow up boomers, it is 2023 lol

Yes I will Switch jeje is more simple

The video started saying that is better for juniors to see inject so they can see what's going on, and then automatically is criticising the use is super explicitly adding all the dependencies(which it will hide for junior the behaviour). And worst is magic, because inject is working there as a decorator, in order to be able to inject those things. There's a reason of explicity telling things to another dev. I believe that inject on constructor is cleaner because you can use the same idea with other injectors. If you want to reuse those classes in whatever place outside angular, it will still work. Also, you will know explicitly what classes depends and you can use it event without a fancy injector.

Funny/interesting that Spring Framework has shifted from field injection to constructor injection and Angular might be doing the opposite.