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(common): reflect input type in context #33997
Conversation
4d4e404
to
adf9934
Compare
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.
can you please split this into two commits and document each change and what is the user-facing fix/impact because when users read about this change in the changelog they will not have any idea about what this does, or mean to them.
I'm assuming that this is a fix for #33527. Can you please state that in the commit message?
Lastly, any chance we we can add some tests for this? I'm assuming that we currently don't have any good infra to test typechecking changes like this unless we write a ngtsc specific test. Is that right?
I've kicked off a presubmit for this change in the meantime to make sure that there are no surprises.
also, this should target the 9.0.x branch as well because otherwise we won't be able to roll this out until v10. (I updated the target label) |
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.
Regarding tests, I think the most valuable way would still be ngtsc's template type checking tests. I feel this way because those tests exercise real Angular templates.
As an alternative, a test could mimic the code that the type checker generates, as to assert that type inference works as expected. Such tests however are most appropriate to be run using https://github.com/microsoft/dtslint, which we don't currently have anywhere AFAIK. Also, I would consider them brittle as there's no guarantee that they are accurate, hence my preference for actual ngtsc template type checking tests.
adf9934
to
42c316d
Compare
I've addressed the feedback. Can you take another look @JoostK @IgorMinar? |
42c316d
to
df1e844
Compare
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 would love to see template type checker tests. If you need help with that, please let me know.
private _thenTemplateRef: TemplateRef<NgIfContext<T>> = null !; | ||
private _elseTemplateRef: TemplateRef<NgIfContext<T>> = null !; | ||
private _thenViewRef: EmbeddedViewRef<NgIfContext<T>> = null !; | ||
private _elseViewRef: EmbeddedViewRef<NgIfContext<T>> = null !; |
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 these private fields can keep the | null
, as it keeps the implementation safe against nulls.
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.
fyi: g3 is looking good. @crisbeto can you please address Joost's feedback?
I have all the feedback addressed locally, but it uncovered some issues with the new signatures. I'll pair up with Joost tomorrow. |
Fixes `NgForOf` not reflecting the type of its input in the `NgForOfContext`.
df1e844
to
ac43930
Compare
All the issues and feedback should addressed now. Thank you for the help with the tests @JoostK! |
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.
In the NgIf
commit, could you include a fixes note for #31556?
Fixes the content of `NgIf` being typed to any. Fixes angular#31556.
ac43930
to
66e8ed4
Compare
Done. |
Fixes `NgForOf` not reflecting the type of its input in the `NgForOfContext`. PR Close #33997
This is a follow-up to angular#33997 where some new generic parameters were added without defaults which is technically a breaking change. These changes add the defaults.
This is a follow-up to angular#33997 where some new generic parameters were added without defaults which is technically a breaking change. These changes add the defaults.
This is a follow-up to angular#33997 where some new generic parameters were added without defaults which is technically a breaking change. These changes add the defaults.
It seems like there should be a test for how this typing behaves with |
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. |
Fixes
NgForOf
not reflecting the type of its input in theNgForOfContext
. Also fixesNgIf
which was typed toany
.Fixes #33527.
Fixes #31556.