The inject function in Angular is not just a toy 

Join my weekly newsletter here: mobirony.ck.page/4a331b9076

Please Joshua, can you make a video about testing componets that are using inject? Ty

Thanks for sharing, I've stuck with constructor for now until the angular team settles on something difinitive, but I use inject for functional guards and when I want to provide a configuration service in the root. So my policy right now is constructor by default, inject where classes are deprecated basically.

I just refactored a guard class to a function and you uploaded a video on the same context! Cool little coincidence 😄

If a class and its constructor only exists to lend DI context to a function, it's nice to be able to just define it as a function instead. That's what I get from this. It enforces the single responsibility principle by abstracting away from the class construct entirely, capturing an injected service into the closure instead. And it's a hell of a lot less verbose.

wouldn't the class approach be more performant because you instantiate and therefore inject services only once instead you would do it for every function call?

Great and gives new perspective looking at these things ❤

Hi Joshua 👋 Is there a performance upgrade if we use the function approach? If I inject only when needed compare to constructor... I know it's not lazy loaded like if(true) import ____ but still?

Interesting and useful.

This might be pretty handy for the new angular tanstack query

I have some old code with event listeners where I needed to provide services as function parameters. If the inject function would have been a thing at that time I wouldn't have so much boilerplate. Currently I use it for cases with abstract classes so I can get around the overblown super constructor.

From when OOP == Class based approach? I must have missed something...

if the lesson service used providedIn: 'root', wouldnt that eliminate the need to provide it in the injector of the component? or would it cause some other issues i dont get?

I will wait until angular 22 and decide weather to continue with angular or not

Please do some courses on angular 17

The changes the Angular team have been making lately make me think it won't be too long before we see functional components, so it's probably worth getting up to speed with things like signals, inject, and other such functions that are basically just React hooks, so that when that transition inevitably occurs, we won't be completely blindsided.

I might be mistaken but think people (me included) weren’t against functional injection. It’s because the syntax from the last video being too closed to ng1 and it triggered a lot of PTSD 😂

got error, NG0203: inject() must be called from an injection context such as a constructor, a factory function, a field initializer, or a function used with `runInInjectionContext`

My major question is: what happens if you use a function that calls inject outside of an injection context? Imo anything that needs a specific "context" should be a compilation error, and @injectables definitely provide that.

One of the reasons I don’t love the function based approach is because the inject function only works in an injection context, (you can only call it while a class is being instantiated), so if you move everything to a function, what’s to prevent another developer from trying to call that function outside of an injection context? Seems, less intuitive to me.

which editor you use ?

where is source code ?

I personally prefer Mixins over the function based approach, and yes for mixins the inject function is pure gold. One Reason I prefer the mixin approach of the function approach you showed, is IMHO testability. I do agree that a service just for that might be overkill (but was necessary in the past). One last thought, Can someone elaborate what the aversion against `this` is? I hear this way to often as an argument pro FP and con OOP. But Neither is `this` a FP feature I would like to point out nor is `this` the OOP feature one should consider OOP for.

Reason for this increasing trend of functions over classes is because it isn't possible for tree shaking to remove unused methods within a class. This isn't just Angular it is all JS frameworks

Hmm I mean, the argument of "need to mark this service with decorator and provide it into the providers" is not valid since CLI does that for you already. I'm not hating or stuff like that, I just wonder what is the real benefit of switching to the function base approach except those syntax changes

Calling the function directly is not dependency injection, and a code smell. There is no way for example to replace the factory function with a mock for testing

Please zoom a bit your screen. It’s very hard in your videos to see what’s going on. Thanks

Can't understand the angular vs react debate. If there's an upside to the framework fatigue, is that we learn from each other, and listen to the community for a better DX.

Angular using classes is one of the regrets from the angular creator.

Oh boy... The idea of just "willy-nilly" using inject() all over the place just because its easier , hurts my brain. The concept of inject() is in most DI containers is called "Service Location" and is an anti-pattern. The reason you inject into your constructor is so that at a glance you can easily see the dependencies of your services. Can you imagine a large project looking at one of your services and not being able to see it's dependecies without scanning every line of code for "inject()"? what a nightmare. There are use cases for Service location for sure.. I would use it when implementing the Factory Pattern for example. These abilities to just spawn services out of thin air seems cool at first, but trust me the inject function is like giving you just enough rope to hang yourself with.