Typescript: Solicitud para cambiar currentTarget en la interfaz de eventos para lib.d.ts

El objeto XMLHttpRequest también puede ser currentTarget pero no es Element / HTMLElement. Quizás esa sea la razón detrás de esto. ¿El tipo genérico mejoraría esto?

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

Parece que será de gran ayuda para mejorarlo.

Enviado desde mi iPhone

El 3 de agosto de 2014, a las 13:34, SaschaNaz [email protected] escribió:

El objeto XMLHttpRequest también puede ser currentTarget pero no es Element / HTMLElement. Quizás esa sea la razón detrás de esto. ¿El tipo genérico mejoraría esto?

Evento de interfaz{
/ * ... _ /
currentTarget: T;
/ _ ... * /
}

interfaz EventListener{
(evt: evento): vacío;
}

interfaz HTMLElement {
/ * ... * /
addEventListener (tipo: cadena, oyente: EventListener, useCapture ?: booleano): void;
}
-
Responda a este correo electrónico directamente o véalo en GitHub.

Tenga en cuenta que no todos los objetivos de eventos son Element (http://www.w3.org/TR/DOM-Level-3-Events/#event-types), por lo que la solución aquí tendría que ser más en la línea de la sugerencia de

El problema es que actualmente generamos lib.d.ts, usando un script, basado en un archivo que no podemos hacer público en este momento, y ese archivo está siendo obsoleto en favor de uno nuevo. Por eso, no vamos a realizar mejoras en el script en este momento, pero es de esperar que en el futuro podamos tomar PR en el script / entrada de generación lib.d.ts.

Etiquetando 'Revisitar' por ahora - por favor envíenos un ping sobre esto en un mes y puedo ver dónde estamos.

¿Existe alguna sintaxis para referirse al tipo actual? Creo que esto se puede resolver más fácilmente si podemos hacer este tipo de trabajo:

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

Esa funcionalidad no existe, es algo parecido a lo que se sugiere en # 285 y # 229

Hola a todos, haciendo ping a este hilo. Me encontré con este problema con Event.target . Me imagino que la mayoría de las veces un objetivo es HTMLElement . Es un poco extraño que el tipo predeterminado asuma que no lo es. Probé la sugerencia de

Editar: esto funcionó para silenciar las advertencias: (<HTMLElement>event.target).tagName

@rayshan, la sugerencia fue lo que debería lib.d.ts y el archivo se genera automáticamente basándose directamente en la implementación de Internet Explorer. Entonces, el error que encontró es exacto. En este momento, la única forma de evitarlo es compilar sin la biblioteca integrada ( --noLib ) y usar la solución alternativa, o hacer lo que ha hecho, que es lanzar el objetivo. Actualmente, hay una serie de desafíos al tratar con los tipos de retorno del DOM en este momento en TypeScript (principalmente porque el DOM no es el conjunto de API más consistente / estructurado / seguro de tipos / implementado de manera consistente).

Ahora que se fusionó el número 4910, ¿se puede volver a visitar?

@zhengbli podría tener algún contexto sobre el estado de los problemas de lib.d.ts que requieren la generación basada en scripts

RP bienvenidos. aquí hay información sobre la contribución de cambios lib.d.ts: https://github.com/Microsoft/TypeScript/blob/master/CONTRIBUTING.md#contributing -libdts-fixes

Me encontré con este TS2339: Property 'result' does not exist on type 'EventTarget' en JS FileReader onload , y otra advertencia para getSummary() en el evento pasado a FileReader's onerror .

Mi solución, para suprimir las horribles líneas onduladas rojas ;-) es la siguiente:

interface FileReaderEventTarget extends EventTarget {
    result:string
}

interface FileReaderEvent extends Event {
    target: FileReaderEventTarget;
    getMessage():string;
}

Luego en mi aplicación:

reader.onload = function(fre:FileReaderEvent) {
        var data = JSON.parse(fre.target.result);
        ...
    }

Los códigos JS generados se ven bien y funcionan para mí. ¿Se podría agregar este tipo de solución, para tipos de eventos JS inusuales, a lib.d.ts?

Supongo que mi solución es demasiado simplista. Pero ayudaría saber por qué.

Me encantaría solucionar este problema. Pero como veo, la única referencia a currentTarget está dentro de los archivos webworker.generated.d.ts generados en el generador de TSJS. No tengo idea de cómo solucionar esto 😞
Realmente espero que alguien pueda solucionar este problema de casi 3 años. Tales errores pueden ser la razón por la que a menudo escucho a la gente decir que TypeScript es difícil de usar y eso realmente me entristece.

Bien. Intenté comenzar a resolver este problema. Creo un PR https://github.com/Microsoft/TSJS-lib-generator/pull/202
Con suerte, esto va en la dirección correcta.

Recibo Property 'getBoundingClientRect' does not exist on type 'EventTarget'. . Creo que es una buena idea.

Bueno, el PR está pendiente desde hace casi 2 meses. Analizaré esto si hay algo que se pueda hacer para acelerarlo.

Sería realmente genial si pudiéramos tener currentTarget genérico, de modo que, por ejemplo, HTMLInputElement.onchange pueda ser del tipo (event: Event<HTMLInputElement>) => void para que event.currentTarget.value funcione sin elenco o escriba anotaciones. Los mecanografiados para React hacen esto, pero dom.lib.d.ts desafortunadamente no.

Esto está bloqueado por un problema de rendimiento causado por los genéricos, ya que la introducción de genéricos duplica el uso de memoria 😭

¿Estos problemas de rendimiento se aplican igualmente a los tipos de React?

lib.d.ts no incluye los tipos de React, pero puede probarlo agregando --diagnostics al comando.

@felixfbecker , personalmente, dudo que esto se solucione pronto. Supongo que la mayoría de la gente ya creó su solución o abandonó TypeScript. También es por eso que hay tan pocas personas que se enfrentan a este problema.

Este problema aún existe en la versión 1.18.0 (1.18.0)

Hola,

El mismo problema con ... y supongo que aún no se ha solucionado.

cuando señalo mi proyecto angular 4 para producción, aparece el problema, de lo contrario, mientras estoy usando solo ng serve ... esto funciona bien. Así que supongo que hay algo relacionado con la forma en que angular administra los archivos de producción.

Espero algún progreso en este tema. Es difícil manipular dom con Typecript.

Este problema tiene cuatro años y el RP correspondiente hace casi un año. Dudo que esto se solucione pronto.

Este problema existe desde hace 4 años, pero aún no se ha solucionado.

Hay una solución disponible en https://github.com/Microsoft/TSJS-lib-generator/pull/207
Pero @saschanaz está bloqueando en función del rendimiento.

Casting party tonite a las 11 - descarga las pestañas de tu navegador:
confirmationMessage(event: BeforeUnloadEvent): any {
const activeElement: HTMLElement = <HTMLElement>(<Document>event.target).activeElement;

: bailando_men:

¿Qué hay de agregar

    readonly currentTarget: Element | null;
    readonly target: Element | null;

en UIEvent solamente? Esto no es muy específico, pero hace feliz a la mayoría del código.
Quizás incluso sin | null como en un evento de UIE, ambos siempre están configurados

mismo problema aquí. Estaba tratando de usar Vue con Typescript y quería obtener el valor de un campo de entrada mientras el usuario escribía. Pero event.target.value no pasaría el verificador de tipo aunque, creo, un texto inout siempre debe producir tales campos para tal evento

Nos deshicimos del error agregando type any a nuestro código:

this.url = (<any>event).target.result;

¿Qué hay de escribir Event y 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> {
  ...
}

Encontré este problema mientras usaba FileReader, una conversión simple al tipo correcto lo corrige

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

¿Hay alguna actualización sobre este tema? Sería útil tenerlo sin forzar la transmisión event.target cada vez o cualquier evento de transmisión (como @gautamkrishnar anteriormente). También está abierto desde 2014. ¡Gracias!

De hecho, sería bueno tener algún tipo de respuesta oficial a este problema antes de su sexto cumpleaños.

Sí, esta es probablemente la molestia número 1 durante todo el día cuando se trabaja con DOM, JSX, etc.

De hecho, es la única molestia diaria que tengo, e imagino que un millón de personas la padecen durante todo el día.

Es realmente difícil entender por qué esto no tiene ninguna prioridad.

Lo mismo para event.target. Un escenario muy común es agregar un controlador de clics a un elemento padre cuando los hijos aún no existen y cuando habrá muchos hijos. Una prueba simple para event.target.tagName o incluso classList es una cosa común que hago. Funciona ... lo he usado durante muchos años. No obtengo intellisense para tagName / classList ya que EventTarget no está clasificado como HTMLElement, pero funciona.