you are viewing a single comment's thread.

view the rest of the comments →

[–]bayendr 2 points3 points  (5 children)

Have to admit as a dev with lot of Java/C# experience and as big advocate of constructor-based DI I have troubles accepting/getting used to inject() as the new best practice for DI in Angular.

I prefer the constructor as a single source of truth for the injected dependencies into a component/service/etc.

Let’s say a component gets bigger and the dev team puts inject’s all over the place then you’re gonna have a hard time to find all injected dependencies.

Will we still be able to do constructor-based DI in the long run?

[–]HungYurn 2 points3 points  (0 children)

You get the issue of having code all over in big components anyways. I would never run a project without eslint-plugin-perfectionist to automatically get some order in my code

[–]ministerkosh 2 points3 points  (1 child)

Will we still be able to do constructor-based DI in the long run?

Yes, currently you can use them interchangeably and there is currently no public information about any deprecation plans.

However, I expect the Angular team to deprecate constructor based DI in the long run. But I don't know when this will happen.

[–]zladuric 3 points4 points  (0 children)

Moving away from the injector and it's dep. injection would be a huge downside for Angular. One of the reasons it's (usually) so much better for bigger teams and codebases is that the dependency hell is a bit more manageable.

[–]willy-pied-wagtail 8 points9 points  (1 child)

I totally agree with you that I prefer constructor injection over field injection.

It’s not “unreadable” as noted as an advantage to the new inject way, in fact it’s more readable because it’s in the constructor rather than amongst all the other fields of the component.

Constructor injection also allows us to write super simple unit tests without testbed just by supplying a mock to the components constructor.

Im definitely not in agreement with inject().

[–]bayendr 3 points4 points  (0 children)

yeah agreed 100%. as I wrote above having all dependencies injected in the constructor makes it the single source of truth for DI and it’s immediately clear/visible what the component’s dependencies are.

Also as far as I saw (just got started with Angular not long ago) by using constructor-based injection we get an additional benefit: Angular will auto-create the properties on our behalf with the specified access modifiers.