Typescript: Solicitação para alterar currentTarget na interface de eventos para lib.d.ts

O objeto XMLHttpRequest também pode ser currentTarget, mas não é Element / HTMLElement. Talvez seja essa a razão por trás disso. O tipo genérico melhoraria isso?

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 ajudará muito a melhorá-lo.

Enviado do meu iPhone

Em 3 de agosto de 2014, às 13:34, SaschaNaz [email protected] escreveu:

O objeto XMLHttpRequest também pode ser currentTarget, mas não é Element / HTMLElement. Talvez seja essa a razão por trás disso. O tipo genérico melhoraria isso?

interface Event{
/ * ... _ /
currentTarget: T;
/ _ ... * /
}

interface EventListener{
(evt: Evento): vazio;
}

interface HTMLElement {
/ * ... * /
addEventListener (tipo: string, ouvinte: EventListener, useCapture ?: boolean): void;
}
-
Responda a este e-mail diretamente ou visualize-o no GitHub.

Observe que nem todo alvo de evento é um Element (http://www.w3.org/TR/DOM-Level-3-Events/#event-types), então a solução aqui teria que ser mais seguindo as linhas da sugestão de

O problema é que atualmente geramos lib.d.ts, usando um script, baseado em um arquivo que não podemos tornar público no momento, e esse arquivo está sendo preterido em favor de um novo. Por causa disso, não faremos melhorias no script neste momento, mas esperamos que no futuro possamos fazer PRs no script / entrada de geração lib.d.ts.

Marcando 'Revisitar' por enquanto - envie um ping para nós em um mês e eu posso ver onde estamos.

Existe alguma sintaxe para se referir ao tipo atual? Acho que isso pode ser resolvido mais facilmente se pudermos fazer este tipo de trabalho:

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

Essa funcionalidade não existe, é algo parecido com o que é sugerido em # 285 e # 229

Olá a todos, executando ping neste tópico. Encontrei este problema com Event.target . Eu imagino que na maioria das vezes um alvo seja HTMLElement . É um pouco estranho que o tipo padrão presuma que não. Tentei a sugestão de @SaschaNaz e encontrei o problema do "identificador duplicado" (desculpe, posso estar faltando alguma coisa, sou muito novo no TypeScript).

Editar: funcionou para silenciar os avisos: (<HTMLElement>event.target).tagName

@rayshan a sugestão foi para o que deveria ir para o arquivo lib.d.ts e o arquivo é gerado automaticamente com base diretamente na implementação do Internet Explorer. Portanto, o erro que você encontrou é preciso. No momento, a única maneira de contornar isso é construir sem a lib embutida ( --noLib ) e usar a solução alternativa, ou fazer o que você fez, que é lançar o destino. Atualmente, há uma série de desafios para lidar com os tipos de retorno do DOM no TypeScript (principalmente porque o DOM não é o conjunto de APIs mais consistente / estruturado / seguro de tipo / implementado de forma consistente).

Agora que # 4910 foi mesclado, isso pode ser revisado?

@zhengbli pode ter algum contexto sobre o status de problemas lib.d.ts que requerem geração baseada em script

PRs bem-vindos. aqui estão algumas informações sobre como contribuir com as alterações de lib.d.ts: https://github.com/Microsoft/TypeScript/blob/master/CONTRIBUTING.md#contributing -libdts-fixes

Encontrei TS2339: Property 'result' does not exist on type 'EventTarget' no JS FileReader onload e outro aviso para getSummary() no evento passado para onerror do FileReader.

Minha solução, para suprimir as horríveis linhas onduladas vermelhas ;-) é a seguinte:

interface FileReaderEventTarget extends EventTarget {
    result:string
}

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

Então, em meu aplicativo:

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

Os códigos JS gerados parecem bons e funcionam para mim. Esse tipo de solução, para tipos de eventos JS incomuns, poderia ser adicionado a lib.d.ts?

Suponho que minha solução seja excessivamente simplista. Mas ajudaria saber por quê.

Eu adoraria corrigir esse problema. Mas, como vejo, a única referência a currentTarget está dentro dos arquivos webworker.generated.d.ts gerados no gerador TSJS. Não tenho ideia de como consertar isso 😞
Eu realmente espero que alguém consiga corrigir esse problema de quase 3 anos. Esses erros podem ser a razão pela qual freqüentemente ouço as pessoas dizerem que o TypeScript é difícil de usar e isso me deixa muito triste.

Bem. Tentei começar a resolver esse problema. Eu crio um PR https://github.com/Microsoft/TSJS-lib-generator/pull/202
Esperançosamente, isso está indo na direção certa.

Estou recebendo Property 'getBoundingClientRect' does not exist on type 'EventTarget'. . Eu acho que isso é uma boa idéia.

Bem, o PR está pendente há quase 2 meses. Vou verificar se há algo que possa ser feito para acelerar o processo.

Seria muito bom se currentTarget fosse genérico, de modo que, por exemplo, HTMLInputElement.onchange pudesse ser do tipo (event: Event<HTMLInputElement>) => void para que event.currentTarget.value funcionasse sem qualquer elenco ou digite anotações. As tipificações para React fazem isso, mas dom.lib.d.ts infelizmente não.

Isso é bloqueado por problemas de desempenho causados ​​por genéricos, pois a introdução de genéricos dobra o uso de memória 😭

Esses problemas de desempenho se aplicam igualmente às tipificações React?

lib.d.ts não inclui tipificações React, mas você pode testá-lo adicionando --diagnostics ao comando.

@felixfbecker Eu pessoalmente duvido que isso seja corrigido em breve. Acho que a maioria das pessoas já criou sua solução alternativa ou abandonou o TypeScript. É também por isso que há tão poucas pessoas enfrentando esse problema.

Este problema ainda existe na versão 1.18.0 (1.18.0)

Olá,

Mesmo problema com ... e acho que ainda não foi corrigido.

quando sinalizo meu projeto angular 4 para produção, o problema aparece, senão, enquanto estou usando apenas ng serve ... funciona bem. Então eu acho que há algo relacionado a como o angular gerencia os arquivos de produção.

Espero algum progresso neste assunto. É difícil manipular dom com Typescript.

Este problema tem quatro anos e o PR correspondente quase um ano, duvido que isso seja corrigido tão cedo.

Este problema existe há 4 anos, mas ainda não foi corrigido.

Há uma correção disponível em https://github.com/Microsoft/TSJS-lib-generator/pull/207
Mas @saschanaz está bloqueando com base no desempenho.

Festa do elenco esta noite às 11 - descarregue as guias do navegador:
confirmationMessage(event: BeforeUnloadEvent): any {
const activeElement: HTMLElement = <HTMLElement>(<Document>event.target).activeElement;

: dancing_men:

Que tal adicionar

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

em UIEvent apenas? Isso não é muito específico, mas deixa a maior parte do código feliz.
Talvez mesmo sem | null como em um UIEvent ambos estão sempre definidos

mesmo problema aqui. Eu estava tentando usar o Vue com Typescript e queria obter o valor de um campo de entrada conforme o usuário digitava. Mas event.target.value não passaria no verificador de tipo, embora - eu acho - um texto inout deva sempre produzir tais campos para tal evento

Nós nos livramos do erro adicionando o tipo any ao nosso código:

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

Que tal digitar Event e 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> {
  ...
}

Eu encontrei esse problema ao usar o FileReader, uma conversão simples para o tipo correto 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);

Há alguma atualização sobre este tópico? Seria útil tê-lo sem forçar o casting event.target todas as vezes ou em qualquer evento de casting (como @gautamkrishnar fez acima). Também está aberto desde 2014. Obrigado!

Na verdade, seria bom receber algum tipo de resposta oficial a este problema antes do seu 6º aniversário

Sim, este é provavelmente o principal incômodo de um dia inteiro ao trabalhar com DOM, JSX, etc.

Na verdade, é o único incômodo diário que tenho - e imagino que um milhão de pessoas tenham isso, o dia todo.

É muito difícil entender por que isso não tem nenhuma prioridade.

O mesmo para event.target. Um cenário muito comum é adicionar um manipulador de cliques a um elemento pai quando os filhos ainda não existem e quando haverá muitos filhos. Um teste simples para event.target.tagName ou mesmo classList é algo comum que eu faço. Funciona .... uso há muitos anos. Não recebo intellisense para tagName / classList, pois EventTarget não é classificado como HTMLElement, mas funciona.