Language-tools: Unterstützen Sie benutzerdefinierte Ereignisse für native DOM-Elemente

Ich weiß nicht, ob es eine Möglichkeit gibt, dass es nur für Elemente mit der Aktion gilt. aber Sie können es so global verfügbar machen.

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

Wir könnten unsere Eingaben auch mit „auf CustomEvent<any> zurückgreifen“ verbessern, aber ich würde es lieber nicht tun, weil andere sich darauf verlassen könnten, dass die Eingaben einen „existiert nicht“-Fehler ausgeben, wenn sie sich bei einem Ereignis vertippen. Ich würde es tun okay mit so etwas, wenn es nur auf Elemente mit Aktionen angewendet wird, aber ich bin mir nicht sicher, wie wir das implementieren würden.
Aus der Aktion auf den Typ zu schließen, halte ich für eine nahezu unmögliche Aufgabe. Vielleicht können wir einen Weg finden, den Benutzer die Aktion und ihre möglichen Ereignisse explizit eingeben zu lassen.

Danke, den Benutzer explizit die Aktion eingeben zu lassen oder explizit zu wählen, wann auf CustomEvent<any> zurückgegriffen werden soll, wäre wahrscheinlich das beste Szenario, aber die Lösung von @ jasonlyu123 ist jetzt gut genug für mich. Danke für die tolle Arbeit!

Ich habe mir das nochmal angeschaut und bin mir jetzt unschlüssig, wie ich am besten vorgehe.

Option 1: Silence-Fehler

Wir könnten den Fehler zum Schweigen bringen, wenn es sich um ein on:XX -Ereignis für ein DOM-Element mit einer use:YY -Direktive handelt. Der Nachteil ist, dass das Ereignis implizit vom Typ any ist. Es erfasst möglicherweise auch nicht alle Fälle, da Svelte von Natur aus so dynamisch ist, dass jemand CustomEvents zum Blubbern bringen könnte.

Option 2: Fallback CustomEvent<any> hinzufügen

Wir würden im Wesentlichen & {[key: string]: CustomEvent<any>} zu allen intrinsischen Elementtypisierungen hinzufügen. Das bedeutet, dass _jedes_ Attribut, das oben nicht aufgeführt ist, auf CustomEvent<any> zurückfällt. Dies würde das Problem der „dynamischen Natur“ und des „impliziten beliebigen“ Problems von Option 1 beheben. Aber es ist auch falsch, wenn jemand ein benutzerdefiniertes Attribut wie myownAttribute verwendet.

Option 3: Fallback any hinzufügen

Wie Option 2, nur dass wir einen & {[key: string]: any} Fallback hinzufügen. Das bedeutet, dass alles, was nicht passt, auf irgendeinen zurückfällt. Dies passt am besten zur dynamischen Natur des DOM, auf Kosten von Tippfehlern.