[fbrchps]

Biggest advantage I've seen from using it, is the ability to quickly get into old code. Sure, well I'm writing it. I have a mental understanding of all the different types, but I don't two years down the line.

Also, when multiple people are working on the same code, it's nice that they all are forced to spell things the same way...

[jdthedisciple]

I recently created a new NextJS project.

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.

[SebastianKra]

So you formed your strong opinion, based on one hour of trying it. Gotcha.

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.

[rcfox]

It's impossible to try to debug your problem with so little to go on. Maybe the type was unioned with something incompatible. At some points, you need to resort to runtime type checking: `if (x instanceof HTMLInputElement) { // TS will know it's a HTMLInputElement at this point } `

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.

[explaininjs]

Just type (… as HTMLInputElement) and be done with it. It’s really not that hard.

[jdthedisciple]

Duh, that's what I did. And every other variant one can possibly think of. To no avail.

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.

[explaininjs]

Show a sample of the issue if you can.

[jdthedisciple]

The code in question:

    (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);
            }
        }
    }

TS wouldn't accept it. My guess is it's not cluttered enough.

My final vanilla version OTOH:

    (e) => {
        const t = e.target;
        if (t.files) {
            const file = t.files[0];
            myImageElem.src = URL.createObjectURL(file);
        }
    }

How is the latter not a million times more elegant? Why do I need to clutter everything with types that I won't even think twice about?

[SebastianKra]

That second version is literally 100% verified and valid Typescript.

`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.

[Dylan16807]

Well I haven't ever used next.js in particular, but if I go open a .tsx file and add <input type="file" onChange={[final vanilla version code]} />, it works fine.

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]) {

If I keep (e: Event), then the code with "instanceof" works, as does:

  let t = e.target as HTMLInputElement;
  if (t.files && t.files[0]) {

[consilient]

`(e: Event) =>` means you accept any event whatsoever.