Also, when multiple people are working on the same code, it's nice that they all are forced to spell things the same way...
For my little site I needed an input element with type=file.
So I was getting started, with TypeScript and all, like the swaggest of web developers.
Came the moment for the actual file input:
TypeScript REFUSED to accept the input element's type as "HTMLInputElement" when that is literally its type.
After TypeScript eating up about 1 hour or so of my time, I decided to get rid of that piece of sh*t for squiggly underlining all my code in Red simply because it's too retarded to understand it.
Any of the TypeScript lovers care to explain?
Needless to say, I ultimately went about doing what I wanted in 5 minutes in VanillaJS and was happy ever after.
Call me again when TypeScript does its job correctly.
That's what cost me the hour or two.
This works like a charm in a strictly typed language like C#, but TypeScript just hasn't got it down correctly yet.
(e: Event) => {
let t: EventTarget | null = e.target;
// here "t as HTMLInputElement" did not work
if (t instanceof HTMLInputElement && t.files && t.files[0]) {
const file = t.files[0];
if (file) {
(myImageElem! as HTMLImageElement).src = URL.createObjectURL(file);
}
}
}
My final vanilla version OTOH:
(e) => {
const t = e.target;
if (t.files) {
const file = t.files[0];
myImageElem.src = URL.createObjectURL(file);
}
}
`e` is inferred from `HTMLProps<HTMLInputElement>['onChange']`
`t` is inferred from `e`
`files` is inferred from `t`
No halfway experienced TS developer would write any of these annotations.
If you got the myImageElem from a ref, you may need to add a !, because yes, it's not technically guaranteed that the ref is set by the time the callback is called.
t gets inferred as `EventTarget & HTMLInputElement`
The only error is that "myImageElem" isn't defined by the snippet, which is to be expected.
If I insert your first snippet, it complains that (e:Event) isn't the right type, but (e) or (e:any) makes the whole thing happy (except "myImageElem").
If I remove the imprecise "Event" typing on e, then your first snippet can be simplified to:
let t = e.target;
if (t.files && t.files[0]) {
let t = e.target as HTMLInputElement;
if (t.files && t.files[0]) {It's the ID of a DOM element. No need to define it (for me). But anyway still good I will try your code, thanks.
declare var myImageElem: HTMLImageElement;Enabling Typescript on an existing, untyped project is going to be rough to start. You'll need to gradually increase the strictness levels and perhaps work on typing one module at a time. With an entirely new project, start with maximum strictness, and things will come together much easier. You might need to learn to do things in new ways to make it easier to work with TS, but that doesn't mean it's wrong.
Certainly, 1 hour to attempt to use any new technology is way too little time. I'd say a minimum of a week of honest effort with a new toy project is warranted before deciding whether it's not for you.
As to your problem: Use ˋ... as HTMLInputElementˋ if Typescript wasn't able to narrow your type sufficiently, or you believe that the value of typing this case isn't worth the effort. This should be somewhat rare.
Use ˋ... as unknown as HTMLInputElementˋ, if your idea of the variable is completely different from Typescript. But at that point you likely _have_ made a mistake somewhere.
Use ˋ...: anyˋ if you want to completely turn off checking. In most projects, this has to be explicitly specified for each parameter and declaration.
It gets more verbose, the more unsafe your code is.