report(tsc): infer createElement type from tag name #6637
Conversation
brendankenny
changed the title
| @@ -364,8 +364,7 @@ class ReportUIFeatures { | |||
| // load event, however it is cross-domain and won't fire. Instead, listen | |||
| // for a message from the target app saying "I'm open". | |||
| const json = reportJson; | |||
| window.addEventListener('message', function msgHandler(/** @type {Event} */ e) { | |||
| const messageEvent = /** @type {MessageEvent} */ (e); | |||
There was a problem hiding this comment.
no idea what was going on here. Maybe fixed on the compiler/built-in defs side so it was not only inferred, but inferred as a MessageEvent.
| @@ -18,6 +18,8 @@ | |||
|
|
|||
| /* globals URL self */ | |||
|
|
|||
| /** @typedef {HTMLElementTagNameMap & {[id: string]: HTMLElement}} HTMLElmentByTagName */ | |||
There was a problem hiding this comment.
HTMLElementTagNameMap is the built-in you're talking about?
There was a problem hiding this comment.
HTMLElementTagNameMapis the built-in you're talking about?
yes
| /** | ||
| * @param {string} name | ||
| * @template {string} T | ||
| * @param {T} name |
There was a problem hiding this comment.
can we type this as the keys of the HTMLElementTagNameMap?
There was a problem hiding this comment.
can we type this as the keys of the
HTMLElementTagNameMap?
We could, though it would eliminate the fallback to the generic HTMLElement when a tag name isn't recognized. Maybe we're ok with that in exchange for better completion/stricter checking?
There was a problem hiding this comment.
would we still get helpful completion if it were strict options | string? :)
There was a problem hiding this comment.
strict options | string
sadly no, it's smart about it and coalesces to just string.
There was a problem hiding this comment.
ok, I tried to use just HTMLElementTagNameMap, and we have one place that's unrecognized: 'summary' in
When Edge gets <details> support I imagine that they'll also support <summary> and their WebIDL will get updated and so the tsc types will get updated (I'm surprised it already has 'details' support, honestly), but until then we probably just want to go with how this PR is now.
This is a little silly, but there's a small quality of life improvement, it closes an old TODO, and it eliminates a decent number of type assertions.
Bases the created element type on the tag name passed in, so e.g.
DOM.createElement('a')returns anHTMLAnchorElement, not just a genericElement. If the tag is unknown, falls back to justHTMLElement, which is close enough to correct for us today.Uses the same tag-name-to-element-type map that tsc uses for
document.createElement, just with a union for theHTMLElementfallback instead of the function overload they use (and sinceDOM.createElementcallsdocument.createElementinternally, this type is checked by their type).