Your channel is helping me a lot, oddly enough you are helping me to understand more English, the way you speak slowly is wonderful, and your angular content is amazing!!! Brazilian here
Lots of thanks for sharing your vision, Dmytro! I think the most beneficial thing of this inject() is ability to use it for inheritance, since as You properly mentioned we do keep using inheritance once in a while, and I personally had nervous twitches passing deps through constructor just to satisfy the contract ;)
If you need to use component inheritance for different templates, then the inject() function in the base class looks really useful. Thanks for another great video that explains the concepts as well as real-world application.
Hello, Dmytro! It reminded me of when I pass an injector from a child class to a parent class, but after a short period of time I rewrote everything back. Here is a small example: ` class Base { protected param: Param; protected param1: Param1; constructor(injector: Injector) { this.param = injector.get(Param); this.param1 = injector.get(Param1); } } class Child extends Base { constructor(injector: Injector, private childParam: ChildParam) { super(injector); } } ` When we use the injector as a service locator, then we violate the encapsulation, we also violate the segregation of interfaces, and in general, the service locator is an anti-pattern. Based on that, don't you think it's pretty much the same thing? Because now it is not clear what dependencies are needed to make this class work.
It looks like inject can help a lot with component inheritance. It could be done before, but was kludgy. Is component inheritance still discouraged? if yes can you point me to something describing the issues
i see it really helpful, the code looks cleaner and you can use it a special cases, dont't be afraid i never dislike your video, i think you do a awesome job and me best way to support your job is through thumb up and never down
Hey Dmytro! Thanks for your videos as always great stuff! I just want to point out that while the inject function looks cool and all using it like that basically turns the Dependency Injection pattern into a Service Locator - which is considered an antipattern for mainly hiding dependencies from the consumer. It has some use-cases but in most cases you would always want to stick with proper constructor injection. And btw you can use the inject function in the constructor as a default value and this will still be a DI pattern which is nice. Also I can share one use-case when I use the Service Locator pattern, it was in a base component for table features that was part of public api in the library so basically I did not want users that would create features for table to depend on the implementation details of my base class so I just injected Injector and then inside the constructor was injecting everything else which is basically the same as just using inject function. So in this one case the tradeoff was worth it as now I could change my base class without introducing breaking changes to public api. Anyway that's a lot of text already. Thanks a lot for the content again! Cheers!
Hi Dmytro, great video. Only one question, could be solved the concern about the injectState function with a generic version for example injectState(...) and inside the inject function this generic type? then we could delegate to the injectState function consumer the type specification.
Many thanks for the time you take for creating precious content such this. I've watched it to the end. As you've said using inject function should have a specific reason like what you mentiond. But in general don't you think it's similar to 'Service Locator' which consider as an anti pattetn?
Hello sir, than you for explaining these advanced angular topics in easy way on your channel. Please can you make a video about angular building process, the configuration (angular json) and what do we get after building the app
@@mateuszhaada6837 I'd love to, but there's really nothing specific. I just read a couple of articles, watched a bunch of videos and now in my head it's like compound knowledge. Basically, you should prefer using services with "atomic" logic parts instead of extending one class. The main reason is that you can only extend one class, but you can inject as many services as you want.
Really interesting how it works in the 3rd scenario under the hood. How it understand context it is called from in case we create inject function in separate file and use it somewhere in the code.
@@dav1tt Hmmm, no, he talked about standalone components and lazy loading, but he didn't talked about how services and dependency Injection will work with that new approach.
Hi, hope you're well. I Just want to clarify my knowledge about window object in Angular, this is because I have read that is better to use it like you did in this video, as a Dependency Injection, creating an InjectableToken, but Why? I hope you can give me a hand with that. I really appreciate your videos, thanks!
Hey Dmytro, title of this video is a bit misleading! its inject() function not Inject() ❗❗❗ Inject() is a parameter decorator on a dependency parameter of a class constructor that specifies a custom provider of the dependency. inject() injects a token from the currently active injector. Both of them (Inject and inject) are included into '@angular/core' but the lowercase one is correct. I was struggling two days with this problem and wondering, why Inject(Router) doesn't return router? Please take care of the Title!
At 14:49 how works dependency injection in that scenario? Angular will start searching in the node tree injectors and then in the modules tree injectors to find the provider or maybe has another behavior?
That last part of the video concerning "Inject Functions" looks very ungly for my taste. I mean either you abstract that function into a class, which by the way defeats its purpose because would realy be a "service" or what you simply create a function outside the component class just to be cool? Maybe Im no seeing the full picture. Any way good channel mate. Keep the good work! Cheers
There’s no performance impact. Conditional injection is possible but may be pointless and needed in just few cases because it only allowed in constructor. It rather adds a bit of (in)convenience for DI in inheritable components.
I have mixed feelings about this new functionality. I understand that it can have its use in certain cases, but I don't understand why it is getting so much hype in social media. It seems to me that this is promoting some bad practices/anti-patterns. I read somewhere that this was a hidden gem in the framework, but maybe it was hidden because the Angular team didn't want us to start getting rid of the dependency injection system without a compelling reason. What about testabilty of the components using this way of injecting dependencies?
I feel like Angular is moving back to functional programming because OOP in this case is a verbose way of modeling app structure. It has not much use when it comes to programming logic itself.
Thanks for explanation. I remember I avoided super(....) stuff by injecting Injector in AppModule and assign to some global static variable. And then access all services by GlobalInjector.injector.get(ServiceName). :)
I don't see how they solve different problems. Both are aimed at code reusability, both hide dependencies, both work only in context of React/Angular, both are used to inject services.
💥 Angular courses made by Dmytro - bit.ly/df-courses 💥
✂ Coupon RUclips_DISCOUNT to get a 10%-off discount ✂
Your channel is helping me a lot, oddly enough you are helping me to understand more English, the way you speak slowly is wonderful, and your angular content is amazing!!!
Brazilian here
The most valuable youtube channel related to angular topics. Thanks for sharing!
Lots of thanks for sharing your vision, Dmytro!
I think the most beneficial thing of this inject() is ability to use it for inheritance, since as You properly mentioned we do keep using inheritance once in a while, and I personally had nervous twitches passing deps through constructor just to satisfy the contract ;)
I really appreciate the work you are doing and I improved so much since I find your channel and take your angular course. See you in the next video
Thank you! See you 😉
If you need to use component inheritance for different templates, then the inject() function in the base class looks really useful. Thanks for another great video that explains the concepts as well as real-world application.
Hello, Dmytro!
It reminded me of when I pass an injector from a child class to a parent class, but after a short period of time I rewrote everything back. Here is a small example:
`
class Base {
protected param: Param;
protected param1: Param1;
constructor(injector: Injector) {
this.param = injector.get(Param);
this.param1 = injector.get(Param1);
}
}
class Child extends Base {
constructor(injector: Injector, private childParam: ChildParam) {
super(injector);
}
}
`
When we use the injector as a service locator, then we violate the encapsulation, we also violate the segregation of interfaces, and in general, the service locator is an anti-pattern.
Based on that, don't you think it's pretty much the same thing? Because now it is not clear what dependencies are needed to make this class work.
It looks like inject can help a lot with component inheritance. It could be done before, but was kludgy. Is component inheritance still discouraged? if yes can you point me to something describing the issues
i see it really helpful, the code looks cleaner and you can use it a special cases, dont't be afraid i never dislike your video, i think you do a awesome job and me best way to support your job is through thumb up and never down
Thanks for showing new features.
Hey Dmytro! Thanks for your videos as always great stuff!
I just want to point out that while the inject function looks cool and all using it like that basically turns the Dependency Injection pattern into a Service Locator - which is considered an antipattern for mainly hiding dependencies from the consumer. It has some use-cases but in most cases you would always want to stick with proper constructor injection. And btw you can use the inject function in the constructor as a default value and this will still be a DI pattern which is nice.
Also I can share one use-case when I use the Service Locator pattern, it was in a base component for table features that was part of public api in the library so basically I did not want users that would create features for table to depend on the implementation details of my base class so I just injected Injector and then inside the constructor was injecting everything else which is basically the same as just using inject function. So in this one case the tradeoff was worth it as now I could change my base class without introducing breaking changes to public api.
Anyway that's a lot of text already.
Thanks a lot for the content again!
Cheers!
Thanks a lot for the new video. As always they are very helpful.
Surprised that you still don't have at least 100K subscribers!
Reduced boilerplate is a great thing!
Great video! Thanks!
Great Video, As always.
Very good tutorial. As you mentioned, a key risk with Inject() is the obfuscation of possible hierarchical dependencies.
make injectState generic: injectState(key: keyof T) to have more type safety!
Hi Dmytro, great video. Only one question, could be solved the concern about the injectState function with a generic version for example injectState(...) and inside the inject function this generic type? then we could delegate to the injectState function consumer the type specification.
Your videos are great, thank you for your hard work. Good luck!
Many thanks for the time you take for creating precious content such this.
I've watched it to the end.
As you've said using inject function should have a specific reason like what you mentiond.
But in general don't you think it's similar to 'Service Locator' which consider as an anti pattetn?
Amazing job bro 😎
I can really see the benefit of this injection for example on decorators to inject services.
I have a lots of super calls to carrying the dependencies... So this will be usefull.
Hello sir, than you for explaining these advanced angular topics in easy way on your channel.
Please can you make a video about angular building process, the configuration (angular json) and what do we get after building the app
Nice features!
Great, but how would it be a unit test for this function?
Why would you need to unit test that?
I assume it will be the same, using TestBed to provide mocks
yeah you may have issues in pipelines if not mocked
Great videos man, I always learn a lot. keep up
Great function, what I did to avoid more boilerplate is to use the Injector in the constructor of the base class. But this is even better!
Thank you for these great videos!
Hi, thanks for the news! Can you please describe more about “you should prefer composition over inheritance”?
Never mind, already found tons of information about this :)
@@igorigor806 Please share some sources :D
@@mateuszhaada6837 I'd love to, but there's really nothing specific. I just read a couple of articles, watched a bunch of videos and now in my head it's like compound knowledge. Basically, you should prefer using services with "atomic" logic parts instead of extending one class. The main reason is that you can only extend one class, but you can inject as many services as you want.
Really interesting how it works in the 3rd scenario under the hood. How it understand context it is called from in case we create inject function in separate file and use it somewhere in the code.
Can you make a video talking about Dependency Injection with Standalone components? I am a little confused with that
I think he already talked about that, check previous videos
@@dav1tt Hmmm, no, he talked about standalone components and lazy loading, but he didn't talked about how services and dependency Injection will work with that new approach.
I have concern about testability. Using inject function it is harder to provide dependency mock in your tests.
Hi, hope you're well. I Just want to clarify my knowledge about window object in Angular, this is because I have read that is better to use it like you did in this video, as a Dependency Injection, creating an InjectableToken, but Why?
I hope you can give me a hand with that. I really appreciate your videos, thanks!
Was waiting for ur video.
Hey Dmytro, title of this video is a bit misleading!
its inject() function not Inject() ❗❗❗
Inject() is a parameter decorator on a dependency parameter of a class constructor that specifies a custom provider of the dependency.
inject() injects a token from the currently active injector.
Both of them (Inject and inject) are included into '@angular/core' but the lowercase one is correct.
I was struggling two days with this problem and wondering, why Inject(Router) doesn't return router?
Please take care of the Title!
If you don't inject the services in the constructor and instead use the inject() function, how can you mock the services when doing unit testing ?
this was my question as well
At 14:49 how works dependency injection in that scenario? Angular will start searching in the node tree injectors and then in the modules tree injectors to find the provider or maybe has another behavior?
Hi! No, it has no impact on how DI works. It works the same as if you injected the dependency via constructor.
I think this approach of inheritance could achieve better in angular 15, with directive composition api
But what about services?🙂
@@DecodedFrontend you're right
what about unit test cases?
we can't override services if we go with injector.
You can always provide mocked services in the TestBed inside “providers” properly 🙂
You are always amazing 👌👌
That last part of the video concerning "Inject Functions" looks very ungly for my taste. I mean either you abstract that function into a class, which by the way defeats its purpose because would realy be a "service" or what you simply create a function outside the component class just to be cool? Maybe Im no seeing the full picture. Any way good channel mate. Keep the good work! Cheers
At 3:16 you could use isPlatformBrowser from '@angular/common' to archive the same validation right?
Hey! Yes, you could use something like isPlatformBrowser(platform) ? ... : ... ; and you would achieve the same result.
Waiting for video about reactive form typification
This featua will make Angular simplier tô use, but I have some concerns about the mess that it could become...
so, can we use this inject function for conditional dependency injection; and can this be useful for performance?
There’s no performance impact. Conditional injection is possible but may be pointless and needed in just few cases because it only allowed in constructor. It rather adds a bit of (in)convenience for DI in inheritable components.
I have mixed feelings about this new functionality. I understand that it can have its use in certain cases, but I don't understand why it is getting so much hype in social media. It seems to me that this is promoting some bad practices/anti-patterns. I read somewhere that this was a hidden gem in the framework, but maybe it was hidden because the Angular team didn't want us to start getting rid of the dependency injection system without a compelling reason. What about testabilty of the components using this way of injecting dependencies?
What is the bad side of inject services like this way?
thank you
12:35 refactoring this class would break the open close principle
man you received disklike for stand-alone component. I think was great video
Not a single word about testing. I think it is crucial. It is 2024 and I still prefer constructor injection
using inject function in the base classe instead of injecting them in the constructor, is this a violation of the D solid principle ?
Nice!
You should be saying,-"Boilerplate | Boilerplate code" instead of boil print 👍
What about tests? With this new way my tests are failing
"forget about it, angular is not becoming like react"
great
I feel like Angular is moving back to functional programming because OOP in this case is a verbose way of modeling app structure. It has not much use when it comes to programming logic itself.
Thanks for explanation. I remember I avoided super(....) stuff by injecting Injector in AppModule and assign to some global static variable. And then access all services by GlobalInjector.injector.get(ServiceName). :)
❤🤯
I never really understood the inject and factory pattern 😂
Welcome to the react hooks world, angular folks!
I don't see how they solve different problems. Both are aimed at code reusability, both hide dependencies, both work only in context of React/Angular, both are used to inject services.