fix(compiler-cli): do not type check native controls with ControlValueAccessor#65469
Conversation
Updates the directive analysis to track the public methods of the class.
| node instanceof TmplAstElement && | ||
| (node.name === 'input' || node.name === 'select' || node.name === 'textarea') && | ||
| !allDirectiveMatches.some(getCustomFieldDirectiveType) | ||
| allDirectiveMatches.every((meta) => { |
There was a problem hiding this comment.
I was debating between this and disabling the native control type checking if there are any directives (aside from Field) on the same element. I went with this approach, because the alternative seemed a bit aggressive.
…eAccessor Currently when we detect a `field` binding on a native element, we treat it as a built-in native control. This might not be the case if it's a pre-existing `ControlValueAccessor` relying on the CVA interop. These changes try to detect any CVA-like directive on the element and disable the additional type checking if there are any. Fixes angular#65468.
c6fa096 to
b76d324
Compare
leonsenft
left a comment
There was a problem hiding this comment.
Are CVAs always directives? I know they're generally provided via the NG_VALUE_ACCESSOR token, so is there an edge case where the provided accessor isn't actually a directive, and could we catch that in type checking or no?
|
They're generally always directives so this should cover it. There are cases where it's provided by assigning to |
|
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. |
Currently when we detect a
fieldbinding on a native element, we treat it as a built-in native control. This might not be the case if it's a pre-existingControlValueAccessorrelying on the CVA interop.These changes try to detect any CVA-like directive on the element and disable the additional type checking if there are any.
Fixes #65468.