-
Notifications
You must be signed in to change notification settings - Fork 25.3k
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
fix(language-service): infer context type of structural directives (#35537) #35561
Conversation
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.
Thank you very much for the contribution! The change looks good.
We are in the midst of transitioning to integrate the Ivy compiler into language service, and consequently expression_diagnostics_specs.ts
will be going away soon.
Do you mind moving the tests to packages/language-service/test/diagnostics_spec.ts
?
The custom directive could be moved to packages/language-service/test/project/app/parsing-cases.ts
.
Thank you!
ccac7d7
to
caf518a
Compare
caf518a
to
ad5d097
Compare
Thanks! I have moved the related unit tests. The other cases have been already covered in this file. |
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.
Thank you very much!
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. |
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: #35537, #35426
What is the new behavior?
The type of structural directive context is now correctly inferred instead of any. There was a trick before to manually handle the context of ngFor exported values (getNgForExportedValueType function), this is not needed anymore, because my solutions handle them automatically. New unit tests were added to validate this change and also to ensure the fix is actually working.
Does this PR introduce a breaking change?
Other information
The implementation works like in angular 8, because it relies on the already existing getTemplateContext method. So the context is inferred from the type parameter of injected TemplateRef. The ivy compiler works differently by relying on ngTemplateContextGuard static method. However, the TemplateRef solution will work with much more existing directives and as I understand, full ivy parity was not scope of language-service v9.