Language-tools: Suporte a eventos personalizados em elementos DOM nativos

Criado em 5 ago. 2020  ·  4Comentários  ·  Fonte: sveltejs/language-tools

Sua solicitação de recurso está relacionada a um problema?
Recebo o seguinte erro ao tentar adicionar eventos personalizados em elementos DOM nativos:

Type '{ onswipestart: (event: CustomEvent<any>) => void; onswipemove: (event: CustomEvent<any>) => void; onswipeend: (event: CustomEvent<any>) => void; style: string; class: string; }' is not assignable to type 'HTMLProps<HTMLDivElement>'.
  Property 'onswipestart' does not exist on type 'HTMLProps<HTMLDivElement>'.ts(2322)

Os eventos personalizados são despachados para um elemento div usando a diretiva Sveltes actions/use https://svelte.dev/examples#actions).

Descreva a solução que você deseja
Ser capaz de digitar a verificação de eventos personalizados despachados usando ações Svelte em elementos DOM nativos.

Descreva as alternativas que você considerou
Eu poderia tentar converter o div em um componente Svelte individual, mas de preferência também deve funcionar em elementos DOM nativos.

Contexto adicional

The error message

É assim que eu escuto os eventos personalizados:

<div
  class="bottomSheet"
  class:draggable
  bind:this={bottomSheet}
  use:swipeable
  on:swipestart={handleSwipeStart}
  on:swipemove={handleSwipeMove}
  on:swipeend={handleSwipeEnd}
  style="height:{height};bottom:{bottom};transform:translateY({$coords.ty}px);"
>

Solicitação de pull relacionada para eventos personalizados em componentes Svelte: https://github.com/sveltejs/language-tools/pull/303

enhancement

Comentários muito úteis

Não sei se existe uma maneira de fazer isso se aplicar apenas a elementos com a ação. mas você pode disponibilizá-lo globalmente assim.

declare namespace svelte.JSX {
    interface HTMLAttributes<T> {
        onswipemove?: (event: CustomEvent<number> & { target: EventTarget & T }) => any;
    }
}

Todos 4 comentários

Não sei se existe uma maneira de fazer isso se aplicar apenas a elementos com a ação. mas você pode disponibilizá-lo globalmente assim.

declare namespace svelte.JSX {
    interface HTMLAttributes<T> {
        onswipemove?: (event: CustomEvent<number> & { target: EventTarget & T }) => any;
    }
}

Também poderíamos aprimorar nossas digitações com "retorno para CustomEvent<any> mas prefiro não fazê-lo porque outros podem confiar nas digitações para lançar um erro "não existe" se digitarem incorretamente um evento. tudo bem com algo assim se for aplicado apenas a elementos com ações, mas não tenho certeza de como implementaríamos isso.
Inferir o tipo da ação é uma tarefa quase impossível, eu acho. Talvez possamos encontrar uma maneira de permitir que o usuário digite explicitamente a ação e seus possíveis eventos.

Obrigado, deixar o usuário digitar explicitamente a ação ou escolher explicitamente quando voltar para CustomEvent<any> provavelmente seria o melhor cenário, mas a solução de @jasonlyu123 é boa o suficiente para mim agora. Obrigado pelo ótimo trabalho!

Eu dei uma olhada nisso novamente e agora estou dividido sobre qual é o melhor caminho a seguir.

Opção 1: Silenciar erro

Poderíamos silenciar o erro se for um evento on:XX em um elemento DOM com uma diretiva use:YY . A desvantagem é que o evento é do tipo any implicitamente. Também pode não pegar todos os casos, porque Svelte é tão dinâmico em sua natureza, alguém poderia fazer CustomEvents borbulhantes.

Opção 2: adicionar CustomEvent<any> substituto

Nós essencialmente adicionaríamos & {[key: string]: CustomEvent<any>} a todas as tipagens de elementos intrínsecos. Isso significa que o atributo _any_ que não está listado acima retornará para CustomEvent<any> . Isso corrigiria o problema de "natureza dinâmica" e o problema de "qualquer implícito" da opção 1. Mas também está errado nos casos em que alguém usa um atributo personalizado como myownAttribute .

Opção 3: adicionar any substituto

Como a opção 2, só que adicionamos um fallback & {[key: string]: any} . Isso significa que qualquer coisa que não se encaixa volta a qualquer. Isso se encaixa melhor na natureza dinâmica do DOM ao custo de não pegar mais erros de digitação.

Esta página foi útil?
0 / 5 - 0 avaliações