-
Notifications
You must be signed in to change notification settings - Fork 27k
feat(core): add ng generate schematic to convert to inject #57056
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
f21d1c1 to
cd6744c
Compare
eneajaho
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @crisbeto
I saw that generics case is not supported, for example: ElementRef<HTMLDivElement>
Because inject() doesn't infer the type correctly (check this issue: #53894) I guess, we also need to pass the whole type as a generic to inject.
el = inject<ElementRef<HTMLDivElement>>(ElementRef<HTMLDivElement>)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| import { Component, Inject, Optional, inject } from '@angular/core'; | |
| import { Component, inject } from '@angular/core'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now it's not removing the unused imports. I can look into it for a follow-up since it would involve the code we use to manage imports across all the schematics.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@crisbeto when you look into this, feel free to consider adding this to the ngtsc import manager as we likely should use that at some point.
packages/core/schematics/ng-generate/inject-migration/README.md
Outdated
Show resolved
Hide resolved
packages/core/schematics/ng-generate/inject-migration/README.md
Outdated
Show resolved
Hide resolved
devversion
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM overall. Just some minor comments
packages/core/schematics/ng-generate/inject-migration/README.md
Outdated
Show resolved
Hide resolved
packages/core/schematics/ng-generate/inject-migration/README.md
Outdated
Show resolved
Hide resolved
packages/core/schematics/ng-generate/inject-migration/README.md
Outdated
Show resolved
Hide resolved
packages/core/schematics/ng-generate/inject-migration/analysis.ts
Outdated
Show resolved
Hide resolved
packages/core/schematics/ng-generate/inject-migration/analysis.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can also use the type checker to check if it's nullable— but maybe this is intended to be just AST based
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll double check it, but my assumption was that it might not work if it can't resolve types coming from other files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. It might end up being the same, if the type is defined outside of the file. Although inside files, it would be more correct. Seems minor to not bother if that's the case
packages/core/schematics/ng-generate/inject-migration/migration.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why can't we use the raw text of TypeNode here already?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because it's a bit of a mix of string manipulation and creating an AST.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I 100% follow, but it doesn't matter much, so LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re-reading your comment now and I think I understand the question. If I remember correctly, TS does some sanitization of identifiers. I was a bit afraid that it might mangle a TypeNode that looks something like Foo<Bar<Baz>>.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC it only does this when using a "generated identifier" via e.g. ts.createUniqueIdentifier
packages/core/schematics/ng-generate/inject-migration/migration.ts
Outdated
Show resolved
Hide resolved
packages/core/schematics/ng-generate/inject-migration/migration.ts
Outdated
Show resolved
Hide resolved
Adds the new `ng generate @angular/core:inject-migration` schematic that will convert existing code from constructor-based injection to injection using the `inject` function. The migration also has a few options that should help reduce compilation errors. This migration is slightly different than our usual ones in that it may have to update entire class or constructor declarations. We don't go through the `ts.factory.update*` APIs for this, because it can cause the entire declaration to be re-formatted. Instead, this migration tries to insert strings in a way that won't affect the user's formatting.
|
Good point @eneajaho, I've added it. Thank you for the quick review @devversion 🎉 |
cd6744c to
5c689b1
Compare
eneajaho
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All license links in the top comment point to: https://angular.io/license
Should we move them to: https://angular.dev/license
|
I looked into changing the licenses a few weeks ago, but it turned out to be kinda huge so I decided to leave it for later: #56379 |
|
Apologies for the question, but could you clarify why we are getting a migrator? Did I miss a discussion or statement indicating that inject is now the preferred approach? The last information I saw suggested that we could use any method we preferred, and that there would be a wait for the outcome of the standardization process of the parameter decorators. Since the inject vs. constructor topic is quite polarizing, it might be helpful to release a statement before this change is merged. |
|
@rainerhahnekamp both constructor-based injection and
|
|
Thanks @crisbeto, that was the answer I was looking for! |
|
This PR was merged into the repository by commit fab673a. The changes were merged into the following branches: main |
…7056) Adds the new `ng generate @angular/core:inject-migration` schematic that will convert existing code from constructor-based injection to injection using the `inject` function. The migration also has a few options that should help reduce compilation errors. This migration is slightly different than our usual ones in that it may have to update entire class or constructor declarations. We don't go through the `ts.factory.update*` APIs for this, because it can cause the entire declaration to be re-formatted. Instead, this migration tries to insert strings in a way that won't affect the user's formatting. PR Close angular#57056
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Adds the new
ng generate @angular/core:inject-migrationschematic that will convert existing code from constructor-based injection to injection using theinjectfunction. The migration also has a few options that should help reduce compilation errors.This migration is slightly different than our usual ones in that it may have to update entire class or constructor declarations. We don't go through the
ts.factory.update*APIs for this, because it can cause the entire declaration to be re-formatted. Instead, this migration tries to insert strings in a way that won't affect the user's formatting.