fix(compiler-cli): infer type of event target for void elements #62648
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
angular-robot
bot
added
area: compiler
crisbeto
force-pushed
the
narrow-event-type
branch
3 times, most recently
from
7a37a61 to
7f5efed
Compare
devversion
approved these changes
Jul 16, 2025
Updates the HTML AST to indicate whether a specific element is a void element.
Adds the `ɵassertType` function that will be used during type checking to assert the type of a value.
Currently we infer the target of DOM events to be `EventTarget | null` which is consistent with the built-in types for `addEventListener`. This is due to the fact that users can dispatch custom events, or the event might've bubbled. However, this typing is also inconvenient for some other common use cases like `<input (input)="query($event.target.value)">`, because we don't have the ability to type cast in a template. These changes aim to make some of the cases simpler by inferring the type of `$event.target` if the event is bound on a void element which guarantees that it couldn't have bubbled.
crisbeto
force-pushed
the
narrow-event-type
branch
from
7f5efed to
436d83a
Compare
|
This PR was merged into the repository by commit 527bd77. The changes were merged into the following branches: main, 20.1.x |
crisbeto
added a commit
that referenced
this pull request
Jul 16, 2025
Adds the `ɵassertType` function that will be used during type checking to assert the type of a value. PR Close #62648
crisbeto
added a commit
that referenced
this pull request
Jul 16, 2025
Currently we infer the target of DOM events to be `EventTarget | null` which is consistent with the built-in types for `addEventListener`. This is due to the fact that users can dispatch custom events, or the event might've bubbled. However, this typing is also inconvenient for some other common use cases like `<input (input)="query($event.target.value)">`, because we don't have the ability to type cast in a template. These changes aim to make some of the cases simpler by inferring the type of `$event.target` if the event is bound on a void element which guarantees that it couldn't have bubbled. PR Close #62648
crisbeto
added a commit
that referenced
this pull request
Jul 16, 2025
Adds the `ɵassertType` function that will be used during type checking to assert the type of a value. PR Close #62648
crisbeto
added a commit
that referenced
this pull request
Jul 16, 2025
Currently we infer the target of DOM events to be `EventTarget | null` which is consistent with the built-in types for `addEventListener`. This is due to the fact that users can dispatch custom events, or the event might've bubbled. However, this typing is also inconvenient for some other common use cases like `<input (input)="query($event.target.value)">`, because we don't have the ability to type cast in a template. These changes aim to make some of the cases simpler by inferring the type of `$event.target` if the event is bound on a void element which guarantees that it couldn't have bubbled. PR Close #62648
atscott
added a commit
to atscott/angular
that referenced
this pull request
Aug 7, 2025
…lder angular versions This fixes an issue caused by angular#62648 for older versions of Angular when the newest version of the language service is used. This prevents the TCB from attempting to use the assertType when it does not exist. fixes angular#63046
4 tasks
|
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. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently we infer the target of DOM events to be
EventTarget | nullwhich is consistent with the built-in types foraddEventListener. This is due to the fact that users can dispatch custom events, or the event might've bubbled. However, this typing is also inconvenient for some other common use cases like<input (input)="query($event.target.value)">, because we don't have the ability to type cast in a template.These changes aim to make some of the cases simpler by inferring the type of
$event.targetif the event is bound on a void element which guarantees that it couldn't have bubbled.