In the default TypeScript HTML app from visual studio, I added
HTMLElement
to the first line of the window.onload event handler, thinking that I could provide a type for “el”.
thus:
class Greeter {
element: HTMLElement;
span: HTMLElement;
timerToken: number;
constructor (element: HTMLElement) {
this.element = element;
this.element.innerText += "The time is: ";
this.span = document.createElement('span');
this.element.appendChild(this.span);
this.span.innerText = new Date().toUTCString();
}
start() {
this.timerToken = setInterval(() => this.span.innerText = new Date().toUTCString(), 500);
}
stop() {
clearTimeout(this.timerToken);
}
}
window.onload = () => {
HTMLElement el = document.getElementById('content');
var greeter = new Greeter(el);
greeter.start();
};
I get an error
Compile Error. See error list for details …/app.ts (25,17):
Expected ‘;’
Any clue why? I suspect I am missing something obvious.
The type comes after the name in TypeScript, partly because types are optional.
So your line:
Needs to change to:
Back in 2013, the type
HTMLElementwould have been inferred from the return value ofgetElementById, this is still the case if you aren’t using strict null checks (but you ought to be using the strict modes in TypeScript). If you are enforcing strict null checks you will find the return type ofgetElementByIdhas changed fromHTMLElementtoHTMLElement | null. The change makes the type more correct, because you don’t always find an element.So when using type mode, you will be encouraged by the compiler to use a type assertion to ensure you found an element. Like this:
I have included the types to demonstrate what happens when you run the code. The interesting bit is that
elhas the narrower typeHTMLElementwithin theifstatement, due to you eliminating the possibility of it being null.You can do exactly the same thing, with the same resulting types, without any type annotations. They will be inferred by the compiler, thus saving all that extra typing: