Migrate from constructor-based dependency injection to inject() function

[Mikastark]

Which @angular/* package(s) are relevant/related to the feature request?

upgrade

Description

Hi Angular team :)

First of all, thanks for the hard work and the wonderful new features (special mentions to signals and input-route binding).

Taking from what was said in the last Building Games and Q/A, I think it could be very great to add a schematics to migrate from constructor-based dependency injection to the new inject() function.

Angular team already did something similar in v16 for Standalone APIs and I personally really appreciated what was done.

Proposed solution

Add some clarification on the official documentation to expose advantages of inject() function usage

Alternatives considered

Add a schematics to simplify migration from constructor-based injection.

[ampmonteiro]

And add a section in the docs why inject function instead of constructor.
thanks.

[spock123]

Sounds like a good idea.
I have to say that personally I think the inject() function is so awesome, it really has changed the developer experience to a degree I had not foreseen.
Sorry for hijacking your issue :)

[freshgum-bubbles]

Related to #50439

[rdlabo]

I created eslint rule of https://www.npmjs.com/package/@rdlabo/eslint-plugin-rules .
This can run auto fixt of fix cunstructor-di to inject-di. Please try!

[freshgum-bubbles]

FWIW My issues with this proposal were well-detailed in my original comment. It may be easier to use, but it obscures the dependencies of classes, and causes a few other (potentially hard-to-debug) issues at runtime.

[ShawnTalbert]

Where is the original discussion about moving away from constructor injection towards inject()?

[bjornharvold]

We have a Angular huge codebase and totally agree that having a migration schematic for this would be uber-cool. inject() makes the code look SOO much cleaner.

[XavierDupessey]

Hello,

Since class-based Guards and Resolvers are deprecated, we are encouraged to use the inject() function for functional-based ones. Therefore, for consistency, I would prefer to use it everywhere (in Components, Directives, Services...) but the lack of automated migration tool make it impossible (given the size of our code-base).

I guess that Google, internally, still use constructors otherwise they would have make the migration schematic public?
So, should we continue with DI constructors everywhere we can? After all, the inejct() function is only described as "another option" in the official documentation cf https://angular.io/guide/dependency-injection#injecting-a-dependency

I would love to have an official answer from Google about this practice :)

[vmasek]

I created an Nx generator for migration, there are quite some complex use-cases handled (see the test files).
Even if there is a problem, it is usually easy to spot/fix. It's ideal to run it to get 99% done and then fix the rest manually 😄 .

https://github.com/vmasek/nx-toolkit/tree/main/packages/inject-migration

[erikunha]

I created an Nx generator for migration, there are quite some complex use-cases handled (see the test files). Even if there is a problem, it is usually easy to spot/fix. It's ideal to run it to get 99% done and then fix the rest manually 😄 .

https://github.com/vmasek/nx-toolkit/tree/main/packages/inject-migration

vmasek YOU ARE THE G.O.A.T!

[JeanMeche]

This migration has been shipped in 18.2 !

https://angular.dev/reference/migrations/inject-function

Some context in #57127 :

@rainerhahnekamp both constructor-based injection and inject are supported right now and will continue being supported in the foreseeable future. We're getting this migrator, because:

1. We've seen that there's similar things popping up both internally and externally so there's a clear need for it.
2. We had some requests for it internally so it made sense to just open-source this so that all Angular users can use it.
3. Given that standard decorators don't support function parameters, there may be projects out there that want to switch to inject so that they can turn off experimental decorators.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}