При использовании интерфейса Event из lib.d.ts и присоединении слушателя обратный вызов получит объект типа Event. Однако свойство currentTarget события имеет тип EventTarget (тогда как оно должно иметь тип Element / HTMLElement).
Объект XMLHttpRequest также может быть currentTarget, но не Element / HTMLElement. Может быть, это причина этого. Улучшит ли это универсальный тип?
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;
}
Похоже, это поможет улучшить его.
отправлено из моего Айфона
3 августа 2014 г. в 13:34 SaschaNaz [email protected] написал:
Объект XMLHttpRequest также может быть currentTarget, но не Element / HTMLElement. Может быть, это причина этого. Улучшит ли это универсальный тип?
событие интерфейса
{
/ * ... _ /
currentTarget: T;
/ _ ... * /
}интерфейс EventListener
{
(evt: событие): пусто;
}interface HTMLElement {
/ * ... * /
addEventListener (тип: строка, слушатель: EventListener, useCapture ?: логическое): void;
}
-
Ответьте на это письмо напрямую или просмотрите его на GitHub.
Обратите внимание, что не каждая цель события - это Element
(http://www.w3.org/TR/DOM-Level-3-Events/#event-types), поэтому решение здесь должно быть больше в соответствии с предложением
Проблема в том, что в настоящее время мы генерируем lib.d.ts, используя сценарий, на основе файла, который мы не можем сделать общедоступным в настоящее время, и этот файл устарел и заменен новым. Из-за этого мы не собираемся вносить улучшения в сценарий в настоящее время, но, надеюсь, в будущем мы сможем использовать PR для сценария / ввода генерации lib.d.ts.
Отметьте пока «Revisit» - пожалуйста, напишите нам об этом через месяц, и я увижу, где мы находимся.
Есть ли какой-нибудь синтаксис для ссылки на текущий тип? Я думаю, что это можно решить легче, если мы сможем выполнить такую работу:
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
Этой функции не существует, это что-то вроде того, что предлагается в # 285 и # 229.
Привет всем, пингую эту тему. Я столкнулся с этой проблемой с Event.target
. Я предполагаю, что большую часть времени целью является HTMLElement
. Немного странно, что тип по умолчанию предполагает, что это не так. Я попробовал предложение @SaschaNaz и столкнулся с проблемой «повторяющегося идентификатора» (извините, я что-то
Изменить: это сработало, чтобы заглушить предупреждения: (<HTMLElement>event.target).tagName
@rayshan предлагалось поместить в файл lib.d.ts
и файл автоматически создается на основе реализации Internet Explorer. Итак, ошибка, с которой вы столкнулись, верна. Прямо сейчас единственный способ обойти это - построить без встроенной библиотеки ( --noLib
) и использовать обходной путь или сделать то, что вы сделали, то есть привести цель. В настоящее время существует ряд проблем, связанных с возвращаемыми типами DOM прямо сейчас в TypeScript (в основном потому, что DOM не является наиболее согласованным / структурированным / типобезопасным / последовательно реализованным набором API).
Теперь, когда # 4910 объединен, можно ли к этому вернуться?
@zhengbli может иметь некоторую информацию о статусе проблем lib.d.ts, которые требуют генерации на основе сценария
PR приветствуются. вот некоторая информация о внесении изменений в lib.d.ts: https://github.com/Microsoft/TypeScript/blob/master/CONTRIBUTING.md#contributing -libdts-fixes
Я столкнулся с этим TS2339: Property 'result' does not exist on type 'EventTarget'
в JS FileReader onload
и еще одним предупреждением для getSummary()
в событии, переданном в FileReader onerror
.
Моя работа по подавлению ужасных красных волнистых линий ;-) заключается в следующем:
interface FileReaderEventTarget extends EventTarget {
result:string
}
interface FileReaderEvent extends Event {
target: FileReaderEventTarget;
getMessage():string;
}
Затем в моем приложении:
reader.onload = function(fre:FileReaderEvent) {
var data = JSON.parse(fre.target.result);
...
}
Сгенерированные коды JS выглядят хорошо и у меня работают. Можно ли добавить такое решение для необычных типов событий JS в lib.d.ts?
Я предполагаю, что мое решение слишком упрощено. Но было бы полезно узнать почему.
Я бы хотел исправить эту проблему. Но, как я вижу, единственная ссылка на currentTarget находится внутри сгенерированных файлов webworker.generated.d.ts в генераторе TSJS. Понятия не имею, как это исправить 😞
Я очень надеюсь, что кто-нибудь сможет исправить эту проблему, возникшую почти 3 года назад. Такие ошибки могут быть причиной того, что я часто слышу, как люди говорят, что TypeScript сложен в использовании, и это меня действительно огорчает.
Хорошо. Я попытался начать решать эту проблему. Создаю PR https://github.com/Microsoft/TSJS-lib-generator/pull/202
Надеюсь, это идет в правильном направлении.
Я получаю Property 'getBoundingClientRect' does not exist on type 'EventTarget'.
. Думаю, это хорошая идея.
Что ж, PR ожидается уже почти 2 месяца. Я изучу это, если есть что-нибудь, что можно сделать, чтобы ускорить это.
Было бы действительно здорово, если бы мы могли иметь currentTarget
общим, так что, например, HTMLInputElement.onchange
может иметь тип (event: Event<HTMLInputElement>) => void
так что event.currentTarget.value
работает без приведения или введите аннотации. Типизация для React делает это, а dom.lib.d.ts, к сожалению, нет.
Это заблокировано проблемой производительности, вызванной дженериками, поскольку введение дженериков удваивает использование памяти 😭
Применимы ли эти проблемы производительности в равной степени к типам React?
lib.d.ts не включает типизацию React, но вы можете протестировать ее, добавив к команде --diagnostics
.
@felixfbecker Я лично сомневаюсь, что это скоро
Эта проблема все еще существует в версии 1.18.0 (1.18.0)
Здравствуйте,
Та же проблема с ... и я думаю, что это еще не исправлено.
когда я помечаю свой проект angular 4 для производства, тогда возникает проблема, иначе я использую только ng serve .. это отлично работает. Итак, я предполагаю, что есть что-то связанное с тем, как angular управляет производственными файлами.
Надеюсь на некоторый прогресс в этом вопросе. Управлять dom с помощью Typescript сложно.
Этой проблеме четыре года, и соответствующему PR почти год, я сомневаюсь, что это будет исправлено в ближайшее время.
Эта проблема существует уже 4 года, но до сих пор не исправлена.
Исправление доступно на https://github.com/Microsoft/TSJS-lib-generator/pull/207.
Но @saschanaz блокирует по производительности.
Casting party tonite at 11 - разгрузите вкладки браузера:
confirmationMessage(event: BeforeUnloadEvent): any {
const activeElement: HTMLElement = <HTMLElement>(<Document>event.target).activeElement;
: dancing_men:
А как насчет добавления
readonly currentTarget: Element | null;
readonly target: Element | null;
только на UIEvent
? Это не очень конкретно, но делает большую часть кода счастливой.
Возможно, даже без | null
как в UIEvent, оба всегда установлены
такая же проблема здесь. Я пытался использовать Vue с Typescript и хотел получить значение поля ввода по мере ввода пользователем. Но event.target.value не пройдет проверку типов, хотя - я думаю - текст inout всегда должен создавать такие поля для такого события
Мы избавились от ошибки, добавив в наш код тип any:
this.url = (<any>event).target.result;
А как насчет ввода Event и 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> {
...
}
Я столкнулся с этой проблемой при использовании FileReader, простое приведение к правильному типу исправляет ее
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);
Есть ли обновления по этой теме? Было бы полезно иметь его без принудительного приведения event.target
каждый раз или любого другого события (как
Действительно, было бы неплохо дать какой-то официальный ответ на этот вопрос до его 6-летия.
Да, это, вероятно, самая дневная неприятность номер 1 при работе с DOM, JSX и т. Д.
Фактически, это единственное ежедневное неудобство, которое у меня есть - и я полагаю, что у миллиона людей оно есть в течение всего дня.
Действительно сложно понять, почему это не имеет приоритета.
То же самое и для event.target. Очень распространенный сценарий - добавление обработчика кликов к родительскому элементу, когда дочерние элементы еще не существуют, и когда их будет много. Я обычно делаю простой тест для event.target.tagName или даже classList. Работает .... пользуюсь уже много лет. Я не получаю intellisense для tagName / classList, поскольку EventTarget не классифицируется как HTMLElement, но работает.
Самый полезный комментарий
Я столкнулся с этим
TS2339: Property 'result' does not exist on type 'EventTarget'
в JS FileReaderonload
и еще одним предупреждением дляgetSummary()
в событии, переданном в FileReaderonerror
.Моя работа по подавлению ужасных красных волнистых линий ;-) заключается в следующем:
Затем в моем приложении:
Сгенерированные коды JS выглядят хорошо и у меня работают. Можно ли добавить такое решение для необычных типов событий JS в lib.d.ts?
Я предполагаю, что мое решение слишком упрощено. Но было бы полезно узнать почему.