(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?
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.
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]) {
My final vanilla version OTOH:
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? TS wouldn't accept it. My guess is it's not cluttered enough.