Unpopular opinion: TypeScript is overrated.
After 1 year of Vanilla JS you will know all the types by heart.
All the necessary static type analysis will be happening automatically in your brain.
No cluttered type syntax and linter wars needed.
After 1 year of Vanilla JS you will know all the types by heart.
All the necessary static type analysis will be happening automatically in your brain.
No cluttered type syntax and linter wars needed.
Tell me you’ve never developed large projects on a team without telling me…
It's simply a hurdle rather than a blessing all too often.
No issues with C# however.
I use C# as comparison as it comes from the same house and was arguable used as inspiration for TS.
Hm.
Argued from first principles:
Since TS is a superset of JS,
we can assert that the both constitute opposite ends on the spectrum of static typing.
Thus, surely there are infinitely many levels of possible gracefulness in-between?
IOW: If JS can live with no constraints, then why can't TS live with with slightly more graceful ones than the current?
That's exactly the point: nobody wants to do this in their head, and humans are far worse and less consistent about these kinds of computations than machines. Plus, as the size of a codebase grows, the chance that you have it all in your head approaches 0%.
Also, I'm not sure what "linter wars" have to do with TS?
Sure I say go for it for those super galactic world changing giga projects but most simply aren't that.
A project with well organized, clean code without a lot of junk will be a small, easily overseeable project, for a long long while.
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.
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.
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.
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;But I doubt you’ll be able to keep up with contributions from three other devs to a massive codebase.
Typescript makes it easier to understand what’s going on at a glance (or a hover, or a ctrl+click) - I’m fine with loosey goosey JavaScript for a solo project, or even a two person collaboration, but for a big team effort? I’m gonna need those strict typings to help keep everyone’s contributions consistent.