Typescript: طلب تغيير CurrentTarget in Event واجهة لـ lib.d.ts

تم إنشاؤها على ٢٩ يوليو ٢٠١٤  ·  36تعليقات  ·  مصدر: microsoft/TypeScript

عند استخدام واجهة الأحداث من lib.d.ts ، وإرفاق مستمع ، ستحصل رد الاتصال على كائن من نوع الحدث. ومع ذلك ، فإن الخاصية currentTarget للحدث هي من النوع EventTarget (بينما يجب أن تكون من النوع Element / HTMLElement).

lib.d.ts Suggestion help wanted

التعليق الأكثر فائدة

واجهت هذا 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؟

أعتقد أن الحل الخاص بي مفرط في التبسيط. ولكن من المفيد معرفة السبب.

ال 36 كومينتر

يمكن أن يكون كائن XMLHttpRequest أيضًا CurrentTarget ولكنه ليس عنصرًا / 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 ولكنه ليس عنصرًا / HTMLElement. ربما هذا هو السبب وراء ذلك. هل النوع العام يحسن هذا؟

حدث الواجهة{
/ * ... _ /
CurrentTarget: T ؛
/ _ ... * /
}

واجهة EventListener{
(evt: Event): باطل ؛
}

واجهة HTMLElement {
/ * ... * /
addEventListener (النوع: سلسلة ، مستمع: EventListener، useCapture ؟: boolean): void؛
}
-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub.

لاحظ أنه ليس كل هدف حدث هو Element (http://www.w3.org/TR/DOM-Level-3-Events/#event-types) ، لذا يجب أن يكون الحل هنا أكثر على غرار اقتراح SaschaNaz .

المشكلة هي أننا نقوم حاليًا بإنشاء lib.d.ts ، باستخدام برنامج نصي ، بناءً على ملف لا يمكننا نشره في الوقت الحالي ، ويتم إهمال هذا الملف لصالح ملف جديد. لهذا السبب ، لن نقوم بإجراء تحسينات على البرنامج النصي في هذا الوقت ، ولكن نأمل في المستقبل أن نأخذ العلاقات العامة على نص / إدخال إنشاء lib.d.ts.

وضع علامة على "إعادة الزيارة" في الوقت الحالي - يرجى الاتصال بنا بشأن هذا في غضون شهر ويمكنني معرفة ما وصلنا إليه.

هل هناك أي صيغة تشير إلى النوع الحالي؟ أعتقد أنه يمكن حل هذا بسهولة أكبر إذا تمكنا من القيام بهذا النوع من العمل:

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 وواجهت مشكلة "المعرف المكرر" (آسف ، فقد أفتقد شيئًا ما ، فأنا جديد تمامًا على TypeScript).

تحرير: هذا يعمل على تهدئة التحذيرات: (<HTMLElement>event.target).tagName

rayshan ، كان الاقتراح يتعلق بما يجب lib.d.ts ويتم إنشاء الملف تلقائيًا بناءً على تطبيق Internet Explorer. لذا فإن الخطأ الذي واجهته دقيق. الطريقة الوحيدة الآن للتغلب عليها هي البناء بدون lib المدمج ( --noLib ) واستخدام الحل البديل ، أو القيام بما قمت به ، وهو الهدف. يوجد حاليًا عدد من التحديات للتعامل مع أنواع إرجاع DOM حاليًا في TypeScript (غالبًا لأن DOM ليس مجموعة واجهات برمجة التطبيقات الأكثر تناسقًا / منظمًا / نوعًا آمنًا / تم تنفيذه باستمرار).

الآن بعد أن تم دمج 4910 # ، هل يمكن إعادة النظر فيه؟

قد يكون لدى zhengbli بعض السياق حول حالة مشكلات lib.d.ts التي تتطلب إنشاءًا يستند إلى البرنامج النصي

رحب PRs. إليك بعض المعلومات حول المساهمة بتغييرات 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 يصعب استخدامه وهذا يجعلني حزينًا حقًا.

حسنا. حاولت البدء في حل هذه المشكلة. أقوم بإنشاء علاقات عامة https://github.com/Microsoft/TSJS-lib-generator/pull/202
نأمل أن يكون هذا في الاتجاه الصحيح.

أحصل على Property 'getBoundingClientRect' does not exist on type 'EventTarget'. . انا اعتقد انها فكرة جيدة.

حسنًا ، العلاقات العامة معلقة منذ ما يقرب من شهرين. سأبحث في هذا إذا كان هناك أي شيء يمكن القيام به لتسريع هذا الأمر.

سيكون من الرائع حقًا أن يكون لدينا currentTarget عام ، لذلك على سبيل المثال ، يمكن أن يكون HTMLInputElement.onchange من النوع (event: Event<HTMLInputElement>) => void بحيث يعمل event.currentTarget.value بدون أي طاقم أو اكتب التعليقات التوضيحية. تقوم كتابات React بهذا ، لكن dom.lib.d.ts لا تفعل ذلك للأسف.

تم حظر هذا بسبب مشكلة الأداء التي تسببها الأدوية الجنسية حيث يؤدي إدخال الأدوية إلى مضاعفة استخدام الذاكرة 😭

هل تنطبق مشاكل الأداء هذه بالتساوي على أنواع React؟

لا يتضمن lib.d.ts كتابة React ولكن يمكنك اختبارها بإضافة --diagnostics إلى الأمر.

felixfbecker أنا شخصياً أشك في أن هذا سيتم إصلاحه قريبًا. أعتقد أن معظم الأشخاص قاموا بالفعل بإنشاء حل بديل أو تم التخلي عن TypeScript. لهذا السبب أيضًا يوجد عدد قليل جدًا من الأشخاص الذين يواجهون هذه المشكلة.

لا تزال هذه المشكلة موجودة في الإصدار 1.18.0 (1.18.0)

مرحبا،

نفس المشكلة مع ... وأعتقد أنها لم يتم إصلاحها بعد.

عندما أضع إشارة على مشروعي الزاوي 4 للإنتاج ، تظهر المشكلة ، وإلا ، بينما أستخدم فقط خدمة ng .. هذا يعمل بشكل جيد. لذلك أعتقد أن هناك شيئًا متعلقًا بكيفية إدارة ملفات الإنتاج.

نأمل بعض التقدم في هذه القضية. من الصعب التعامل مع dom باستخدام تنقيط.

هذه المشكلة عمرها أربع سنوات والعلاقات العامة المقابلة لها ما يقرب من عام وأشك في أنه سيتم حلها في أي وقت قريب.

هذه المشكلة موجودة منذ 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 لن يجتاز مدقق النوع بالرغم من - أعتقد - أن النص الداخل يجب أن ينتج دائمًا مثل هذه الحقول لمثل هذا الحدث

تخلصنا من الخطأ بإضافة النوع أي إلى الكود الخاص بنا:

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 كل مرة أو في أي حدث يتم اختياره (كما فعل

في الواقع ، سيكون لطيفًا مع نوع من الرد الرسمي على هذه المشكلة قبل عيد ميلادها السادس

نعم ، ربما يكون هذا هو مصدر الإزعاج الأول الذي يستغرق يومًا عند العمل مع DOM و JSX وما إلى ذلك.

في الواقع ، إنه مصدر الإزعاج اليومي الوحيد الذي أواجهه - وأتخيل أن مليون شخص يعانون من هذا طوال اليوم.

من الصعب حقًا فهم سبب عدم حصول ذلك على أي أولوية.

نفس الشيء بالنسبة لل event.target. السيناريو الشائع هو إضافة معالج النقرات إلى عنصر أصلي عندما لا يكون الأطفال موجودين بعد ، وعندما يكون هناك العديد من الأطفال. اختبار بسيط لـ event.target.tagName أو حتى classList هو أمر شائع أفعله. يعمل .... لقد استخدمته لسنوات عديدة. لا أتحدث عن tagName / classList نظرًا لأن EventTarget غير مصنف على أنه HTMLElement ، ولكنه يعمل.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات