Repository navigation
Request to change currentTarget in Event interface for lib.d.ts #299
Description
Activity
XMLHttpRequest object also can be currentTarget but it is not Element/HTMLElement. Maybe that's the reason behind this. Would generic type improve this?
interface Event<T extends EventTarget> { /* ... */ currentTarget: T; /* ... */ } interface EventListener<T extends EventTarget> { (evt: Event<T>): void; } interface HTMLElement { /* ... */ addEventListener(type: string, listener: EventListener<HTMLElement>, useCapture?: boolean): void; }
Reacted by Remco Haszing, Brian Schlenker, Reymundo Tenorio, Peter Lamby, mrskiro and Yota ToyamaLooks like it'll go a long way to improving it.
Sent from my iPhone
On 3 Aug 2014, at 13:34, SaschaNaz [email protected] wrote:
XMLHttpRequest object also can be currentTarget but it is not Element/HTMLElement. Maybe that's the reason behind this. Would generic type improve this?
interface Event {
/* ... /
currentTarget: T;
/ ... */
}interface EventListener {
(evt: Event): void;
}interface HTMLElement {
/* ... */
addEventListener(type: string, listener: EventListener, useCapture?: boolean): void;
}
—
Reply to this email directly or view it on GitHub.Note that not every event target is an
Element(http://www.w3.org/TR/DOM-Level-3-Events/#event-types), so the solution here would have to be more along the lines of Kagami Sascha Rosylight (@saschanaz)'s suggestion.The problem is that we currently generate lib.d.ts, using a script, based on a file which we can't make public at this time, and that file is being deprecated in favor of a new one. Because of that, we're not going to make improvements in the script at this time, but hopefully in the future we can take PRs on the lib.d.ts generation script/input.
Tagging 'Revisit' for now - please ping us on this in a month and I can see where we're at.
Reacted by Steven, Ahmad Raza, Christian Muñoz, AskPlays and Tomáš HübelbauerIs there any syntax to refer the current type? I think this can be solved more easily if we can do this kind of work:
interface HTMLElement { addEventListener(type: string, listener: EventListener<this>, useCapture?: boolean): void; } var image: HTMLImageElement; var video: HTMLVideoElement; image.addEventListener // receives EventListener<HTMLImageElement> type video.addEventListener // receives EventListener<HTMLVideoElement> type
Hi all, pinging this thread. I ran into this issue with
Event.target. I would imagine most of the time a target is anHTMLElement. It is a little odd that the default type assumes it isn't. I tried Kagami Sascha Rosylight (@saschanaz)'s suggestion and ran into the "duplicate identifier" issue (sorry I may be missing something, I'm pretty new to TypeScript).Edit: this worked to quiet the warnings:
(<HTMLElement>event.target).tagNameRay Shan (@rayshan) the suggestion was for what should go into the
lib.d.tsfile and the file is auto generated based directly on the implementation of Internet Explorer. So the error you encountered is accurate. Right now the only way around it is to build without the built in lib (--noLib) and use the workaround, or do what you have done, which is cast the target. There are currently a number of challenges of dealing with the return types of the DOM right now in TypeScript (mostly because the DOM isn't the most consistent/structured/type safe/consistently implemented set of APIs).Now that #4910 is merged, can this be revisited?
Zhengbo Li (@zhengbli) might have some context on the status of lib.d.ts issues that require script based generation
PRs welcomed. here is some infromation on contributing lib.d.ts changes: https://github.com/Microsoft/TypeScript/blob/master/CONTRIBUTING.md#contributing-libdts-fixes
17 remaining items
What about adding
readonly currentTarget: Element | null; readonly target: Element | null;
on
UIEventonly? This is not very specific, but makes most code happy.
Perhaps even without| nullas on a UIEvent both are always setsame issue here. I was trying to use Vue with Typescript and wanted to get the value of an input field as the user typed. But event.target.value would not pass the type checker even though - i think - a text inout must always produce such fields for such an event
We got rid of the error by adding type any to our code:
this.url = (<any>event).target.result;
Reacted by Mark RousseauReacted by IAMtheIAM, Guardian of the Spring, Aron Gabor and AskPlaysWhat about typing Event and EventTarget?
interface Event<C = any, S = any, T = any> { ... currentTarget: EventTarget<C> | null; srcElement: EventTarget<S> | null; target: EventTarget<T> | null; ... } interface EventTarget<T = any> { ... }
Reacted by Eric Van Der Dijs, Dan Strokirk, AskPlays and Nicolás ScarcellaI encountered this issue while using the FileReader, a simple cast to the correct type fixes it
const fileReader = new FileReader(); fileReader.onload = $ev => { console.log($ev); // type ProgressEvent console.log($ev.target); // type FileReader // console.log($ev.target.result); // editor and autocomplete doesn't show any error console.log(($ev.target as FileReader).result); // casting compiles fine }; fileReader.readAsText(file);
Reacted by Melroy Fernandes, Eleni Afiontzi, Khoa Nguyen, Guardian of the Spring, Lev Izraelit and AskPlaysAre there any updates about this topic? It would be useful to have it without force casting
event.targetevery time or any-casting event (as Gautam krishna R (@gautamkrishnar) did above) . Also this is open since 2014. Thank you!Reacted by Brian Kim, Dean-NC, Lev Izraelit, Aron Gabor, Jacob A. Carpenter, Rhys Lloyd and AskPlaysIndeed, would be nice with some kind of official response to this issue before its 6th birthday
Yep, this is probably the Number 1 day-long nuisance when working with DOM, JSX, etc.
In fact, it's the only daily nuisance I have - and I imagine a million people have this, all day long.
It's really difficult to understand why this doesn't get any priority.
Reacted by Brian Kim, Dean-NC, Alexander Cerutti, Daniel Schuba, Joshua, Guardian of the Spring, mlrsoft, Marcus Lindfeldt, Lev Izraelit, Christian Muñoz and 14 moreSame for event.target. A very common scenario is adding a click handler to a parent element when children don't exist yet, and when there will be many children. A simple test for event.target.tagName or even classList is a common thing I do. It works....have used it for many years. I don't get intellisense for tagName/classList since EventTarget is not classified as HTMLElement, but it works.
Reacted by mlrsoft, v1rtl, Rhys Lloyd and AskPlaysThis is blocked by performance issue caused by generics as introducing generics doubles memory usage 😭
Going to bump this thread since the last post was in 2020. Are the performance issues with generics still there? Is there a concern about introducing performance issues to users with old versions of TS if modern TS can handle things well? Is there anything the community can do? Would a PR be welcome?
The PRs are there, but blocked by performance issues. I would not expect this issue to be solved any time soon. I guess everybody got used to this problem.
Reacted by Gautam krishna R and AskPlaysReacted by Rasmus Schultz, Jonathan Zacsh and AskPlaysWhat I can see is that there is interest in fixing this issue, and there was a PR. The only reason the PR was not merged is because its performance was bad (because of generics). Then the PR was closed, because it wasn't updated anymore.
Now, people are asking for this feature, but there is no new PR with new performance numbers. I don't feel comfortable to implement this feature since I never worked on tsc, though is there anyone else who is able to do so? From the old PR, it doesn't look like it would be a lot of work.
For anyone still interested in this feature, I created a PR here and could use some feedback regarding the performance.
Reacted by Maru Alka, Tomoe and Clément Maisonhaute
When using the Event interface from lib.d.ts, and attaching a listener, the callback will get an object of type Event. However, the Event's currentTarget property is of type EventTarget (whereas it's should be of type Element/HTMLElement).