Jsdom: إضافة دعم لـ MutationObserver

أنا أيضا بحاجة إلى هذا. سأكون على استعداد للعمل على طلب سحب لهذا إذا كان شخص ما يمكن أن يوجهني في الاتجاه الصحيح.

@ SegFaultx64 عنوان URL الذي قدمه schettino72 في المنشور الأول حول هذه المشكلة هو "الاتجاه الصحيح".

عادل بما فيه الكفاية ، لست متأكدًا حتى من كيفية تسجيل المراقبين في مشروع بهذا الحجم. هل هناك مكان يتم فيه تخزين أشياء من هذا القبيل؟

@ SegFaultx64 ليس من الواضح بالنسبة لي ما هي أفضل طريقة لأنني لم ألقي نظرة على هذا الجزء من jsdom. عندما عملت على إصلاح أساليب NS (انظر # 727 ؛ اسميًا ، إنه إصلاح للأخطاء ولكنه يتطلب تغييرات جوهرية في أحشاء jsdom) بحثت عن الهياكل التناظرية وذهبت مع ذلك لتحديد مكان إضافة فئات / بيانات جديدة / إلخ. لقد تقدمت إلى حد كبير بما اعتقدت أنه الأفضل ، فقد أدلى دومينيك ببعض التعليقات ، وقمت بتعديل ما يلزم من تعديل ، وكان هذا هو الحال.

lddubeau حسنًا ، شكرًا على المؤشرات. لقد وجدت بالفعل رقاقة لطيفة المظهر لـ MutationObserver https://github.com/megawac/MutationObserver.js/blob/master/MutationObserver.js. يبدو وكأنه نقطة قفز لطيفة. سأبدأ في هذا لاحقًا اليوم.

نصيحتي الوحيدة هي الاطلاع على https://dom.spec.whatwg.org/ والنظر في تفاصيل مكان إدراج سجل الطفرات. قد يكون العثور على النظراء المناسبين في jsdom أمرًا صعبًا نظرًا لأننا ما زلنا ننتقل إلى معيار DOM الجديد ، ولكن على الأقل ستمنحك المواصفات إرشادات حول ما يجب تنفيذه.

أي تحديثات على هذا؟

@ kresli سحب طلب ترحيب!

ليس لدي أي فكرة عن كيفية القيام بذلك ، لكنني قررت إجراء بعض التجارب. أسوأ حالة أتعلم قليلاً ، أفضل حالة قد أتمكن من المساهمة.

أحاول حاليًا فهم كيفية بناء jsdom وكيف يعمل webidl (ويستخدم في jsdom)

هل سيكون من الممكن الخروج من عنوان الويب هذا على MutationObserver: https://dxr.mozilla.org/mozilla-central/source/dom/webidl/MutationObserver.webidl~~~

أفهمها الآن بشكل أفضل قليلاً - يجب أن تكون الواجهة (الواجهات) المراد استخدامها هي تلك الموضحة هنا: https://dom.spec.whatwg.org/#interface -mutationobserver - أليس كذلك؟

تضمين التغريدة لجعله يعمل في jsdom ، عليك أن تبدأ بأمرين:

• أضف MutationObserver.idl المناسب إلى https://github.com/tmpvar/jsdom/tree/master/lib/jsdom/living/nodes. (في المستقبل ، من المحتمل أن يتم وضعه في مجلد أفضل من ذلك. لكن الإعداد الحالي لدينا يجعل ذلك مزعجًا بعض الشيء ، لذلك يمكنك الاستمرار في العقد حتى تحصل على شيء يعمل.)
• أضف ملف MutationObserver-impl.js إلى هذا المجلد أيضًا. هذا هو المكان الذي يستمر فيه عمل التنفيذ الفعلي. على سبيل المثال ، تقول المواصفات "كل كائن MutationObserver له هذه المفاهيم المرتبطة." من المحتمل أن تكون هذه متغيرات حالة في فئة impl (= application).

ستحتاج بعد ذلك "فقط" إلى تنفيذ طرق الملاحظة ، وقطع الاتصال ، و takeRecords ، بالإضافة إلى المُنشئ ، في فئة الضم. بشكل عام ، يجب أن تحاول اتباع المواصفات قدر الإمكان. ( Sebmaster ، هل يمكنك شرح كيفية عمل المنشئ؟)

في هذه الحالة ، على عكس شيء بسيط مثل CharacterData ، سيتطلب الكثير من تغييراتك تعديل ملفات ضمنية jsdom أخرى. على سبيل المثال ، تقول المواصفات "لكل عقدة قائمة مرتبطة بالمراقبين المسجلين". سيتطلب هذا إضافة متغير حالة إلى Node implant.

تشير المواصفات أيضًا إلى أن "كل وحدة من سياقات التصفح ذات الأصل المتشابه لها علامة قائمة انتظار مركبة لمراقب الطفرة ، والتي لم يتم ضبطها في البداية ، وقائمة مرتبطة بكائنات MutationObserver ، والتي تكون فارغة في البداية." هذا أصعب قليلاً ، لأن "وحدة سياقات التصفح ذات الأصل المتشابه" ليست واضحة في jsdom. ما سأفعله لهذا هو أن أبدأ بمجرد وضعها على كائنات Window. لا تستخدم كائنات النافذة IDL حتى الآن ، لذا ستقوم فقط بإضافة خاصية ذات بادئة سفلية في Window.js. في المستقبل ، يمكننا أن نحاول القلق بشأن التأكد من تتبع الأشياء عبر نوافذ متعددة (على سبيل المثال ، اعتني بإطارات iframe). ولكن في الوقت الحالي تعتبر النافذة مكانًا جيدًا لوضعها.

أخيرًا ، سيتم الاهتمام بالكثير من التنفيذ من خلال إيجاد الأماكن المناسبة "لوضع سجل الطفرات في قائمة الانتظار". إذا انتقلت إلى https://dom.spec.whatwg.org/#queue -a-mutation-record وانقر على "قائمة انتظار سجل الطفرة" ، يمكنك رؤية جميع الأماكن في المواصفات التي تحدث. سيكون هذا صعبًا بعض الشيء لأن jsdom لا يحتوي على نفس الخطافات التي تستخدمها المواصفات عند حدوث الأشياء. ولكن يجب أن يكون قابلاً للتنفيذ ، باستخدام الخطافات _attrModified و _descendantRemoved و _descendant. يحتوي https://github.com/tmpvar/jsdom/blob/master/lib/jsdom/living/attributes.js أيضًا على "عناصر مراقبة طفرة TODO" طوال الوقت.

امل ان يساعد!

رائعة :)

مرة أخرى ، لست من ذوي الخبرة الفائقة مع webidl وقواعد الرموز الأكبر. أنا أيضًا مليء ببعض المواعيد النهائية ؛)

سأبذل قصارى جهدي وأعطيها مرة أخرى خلال الأسابيع القليلة المقبلة. سأحاول أيضًا إجراء حالة اختبار أو اثنتين.

نعم،

لقد وصلت إلى الآن لإنشاء idl و Impl وطلبتهما في window.js.

الآن أحاول إنشاء ملف اختبار له ويمكنني استدعاء MutationObserver () جديد ببادئة النافذة.

const window = jsdom("<html><body><div id='mutation'></div></body></html>").defaultView;

let observer = new window.MutationObserver(function(mutations){
      console.log(mutations);
});

هل أفتقد بعض الحيل هنا أو هل هناك مكان ما أحتاج إليه لفضح MutationObserver ككائن عالمي (يتم استدعاؤه دون استدعائه على كائن النافذة).

لقد أضفت السطر التالي في Window.js

const MutationObserver = require("../living/generated/MutationObserver");

آسف على كل هذا السؤال. أحاول فقط إنشاء بعض نقاط الدخول حتى أتمكن من البدء في اختبار واتباع بنية / نمط jsdom.

آه ، آسف ، لقد نسيت هذا الجزء. ستحتاج إلى إضافة سطر مثل https://github.com/tmpvar/jsdom/blob/28f00b30236d540df1777ca6c2c0ee9e5e19fe5b/lib/jsdom/living/index.js#L28

لدي سؤال يتعلق بمهمة الطفرة في قائمة الانتظار . يبدو أن المواصفات تشير إلى مكان مركزي حيث يتم وضع العديد من المهام الصغيرة في قائمة الانتظار وإخراجها بالترتيب. يمكنني العثور على مثل هذا المكان في jsdom وأعتقد أن فكرة domenic حول تحمل هذه المسؤولية في Window.js ستنجح ( تضيف webkit سجلات الطفرات إلى سلسلة رسائل

هل هناك أي مكونات أخرى في jsdom قد تستفيد من مثل هذا الطابور؟ هل هناك شيء يجب أن أضعه في الاعتبار هنا فيما يتعلق بالهندسة المعمارية والتكامل (المستقبلي)؟

هل سيكون من الأذكى تنفيذ المهام في قائمة الانتظار بناءً على عداد الوقت (هل هناك علامة عالمية في jsdom؟) أو بناءً على بنية رد الاتصال بالوعود / المنجزة؟

أنا أركز على إنجاز التنفيذ الأساسي ثم كتابة حالات اختبار مكثفة لتوجيه التنفيذ المستقبلي.

لذا ، فإن المهمة الدقيقة هي في الأساس process.nextTick(fn) . يعد هذا الأمر أكثر صعوبة بالنسبة لمراقبي الطفرات بسبب الأعمال الدقيقة المركبة و "تنفيذ المهمة الدقيقة المركبة للمهام الفرعية". أعتقد أنه يمكنك في الغالب تجاهل ذلك ؛ jsdom لا داعي للقلق بشأن الأشياء التي يقوم بإعدادها.

لذلك: عندما تقول المواصفات "ضع في قائمة الانتظار مهمة دقيقة مركبة لإخطار مراقبي الطفرات" ، فأنت تفعل process.nextTick(notifyMutationObservers) . بعد ذلك ، داخل notifyMutationObservers ، أعتقد أن الخطوة 3 يمكن أن تكون مجرد حلقة فوق مراقبي الطفرات ، والتي تقوم بتنفيذ الخطوات الفرعية بشكل متزامن.

للاختبارات ، تأكد من مراجعة https://github.com/tmpvar/jsdom/blob/master/Contributing.md. قد تكون هناك بعض اختبارات منصة الويب الحالية التي يمكنك استخدامها (على الرغم من أن هذه الاختبارات ليس من السهل دائمًا اجتيازها للتنفيذ من البداية). وأي اختبارات تقوم بتأليفها يجب أن تكون في مجلد to-upstream ، باتباع هذا التنسيق.

قد لا يكون هذا هو المكان المناسب لطرح الأسئلة ، ولكن لدي بعض المشاكل في فهم كيفية تمرير كائنات مخطط webidl (على سبيل المثال /generated/MutationRecord.js) ذهابًا وإيابًا بين الملفات الضمنية (Node-impl -> MutationObserver-Impl) .

أنا أميل إلى إنشاء الكائنات ككائنات JSON نقية تعكس مخطط MutationRecords وتمرير ذلك من Node-impl إلى MutationObserver عند حدوث طفرة. أعتقد أن هذا من شأنه كسر الطموح لتنفيذ جميع جوانب MutationObservers كما هو موضح في المواصفات.

أظن أن هذا يرجع إلى أنني لست على دراية بهندسة / نموذج كائن / واجهات jsdom webidl. سيساعدني مثال داخل الكود أيضًا في فهم العمل مع / إنشاء / كائنات في ملفات الضم.

ربما يجب أن نوثق هذا في مكان ما ، ولكن هنا يذهب:

بشكل عام ، أي وسيطات تمر عبر واجهة برمجة التطبيقات التي تم إنشاؤها سيتم فكها تلقائيًا / إعادة تشكيلها ، لذلك لن تضطر أبدًا إلى الاهتمام بالكائنات التي تم إنشاؤها - فقط كائنات التنفيذ هي المهمة. باستثناء - ليس حقًا. سيكون هذا هو الحال ، إذا كان لدينا _ كل شيء _ تحولنا بالفعل إلى القائمة على IDL ، وهذا ليس هو الحال. تعمل الوسيطات وقيم الإرجاع ، ولكن في كل مرة تتفاعل فيها مع فئة ليست من فئة IDL (مثل Window) ، سيتعين عليك القيام بعملية unboxing / reboxing عندما تزودهم بأي وسيطات بنفسك (انظر على سبيل المثال https: // github. com / tmpvar / jsdom / blob / master / lib / jsdom / living / events / EventTarget-impl.js # L103 ، حيث يتعين علينا idlUtils.wrapperForImpl / idlUtils.implForWrapper إذا لزم الأمر.

بشكل عام ، تريد إنشاء كائن Impl. للقيام بذلك ، تحتاج إلى الملف الذي تم إنشاؤه واستدعاء createImpl عند تصديره. سوف يتطلب الأمر مصفوفة من args (لوسائط public-constructor) وكائن من وسيطات خاصة (كلاهما متوفر لفئة impl). راجع https://github.com/tmpvar/jsdom/blob/9dd9069354e36c077032f4cbcb1616a7d9e6f0c4/lib/jsdom/living/nodes/Document-impl.js#L549 للحصول على مثال لذلك.

أدرك أن هذا ليس بالعمق الكافي تقريبًا لفهم الأمر برمته (على ما أعتقد) ، لذلك إذا كان لديك شيء أكثر تحديدًا ، فسأكون سعيدًا لشرح المزيد.

شكرًا لك Sebmaster ، لقد ساعد كثيرًا.

نعم ، إن توثيق ذلك ببعض الأمثلة حول كيفية تكامل واستخدام API / الكائنات سيكون مفيدًا ، لكنني أعتقد أنني أعرف ما يكفي للخطوات القليلة التالية.

تحديث سريع!
ستفشل اختبارات W3C إذا اتبع MutationRecord المواصفات (على ما أظن). لقد قدمت تعليقًا في المستودع الخاص بهم.

سأقوم بتحديثها محليًا لغرضي ولكني لست متأكدًا مما إذا كنت سألتزم بها W3C / jsdom. هذا ما لم يكن لدي الوقت لإنهاء هذه المهمة أيضًا.

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

هذا مثير للغاية! هل يمكنك أن تشرح بمزيد من التفصيل ما هي المشكلة؟ لم أكن قادرًا تمامًا على متابعة https://github.com/w3c/web-platform-tests/issues/2482 لذا ربما فقط: ما هي قيمة خاصية سجل الطفرة التي تتوقعها الاختبارات ، وما الذي تتطلبه المواصفات برأيك ؟

تكمن المشكلة في أن الاختبار لا يحدد سجل طفرة كامل للمقارنة به. لذلك في حالة الاختبار الأولى ، سيغير الاختبار قيمة المعرف ونتيجة لذلك سيكون لسجل الطفرة المرتجعة خاصية القيمة القديمة. لم يتم تعريف الخاصية oldValue في الكائن المتوقع وسيفشل الاختبار. كما أفهمها ، يجب أن يحتوي سجل الطفرات دائمًا على جميع الخصائص ، حتى عندما تكون خالية. في هذه الحالة يجب أن تكون DOMString خالية. عندما لا يتم تعيين الخصائص في testcase ، سينتهي الاختبار بمقارنة null (typeof object) مع null (typeof string) والفشل.

يتم إنشاء الاختبارات بشكل كسول ، على سبيل المثال ، يتم تعيين الحقول غير المحددة تلقائيًا على فارغة (كائن). سيؤدي هذا إلى فشل الاختبارات عندما أ) تقوم mutationRecord بإرجاع خاصية لم يتم تعيينها في كائن السجل المتوقع (مثل oldValue) و (ب) عندما تكون خاصية سجل الطفرة DOMstring خالية (على سبيل المثال ، attributteNamespace).

من المنطقي؟

إذا كنت على حق فمن السهل إصلاحه ، لكنه يتطلب متابعة جميع الحالات واحدة تلو الأخرى. قد يكون هذا صعبًا بعض الشيء باعتباره غريبًا على كل من اختبار jsdom و w3c :)

أنا آسف ، هل يمكنك التبسيط؟ أفضل إجابة في النموذج: تتوقع الاختبارات أن تكون قيمة oldValue خالية أو غير محددة ، لكن المواصفات تعطي قيمة "خالية". أو مشابه.

الاختبار المشار إليه أعلاه توقع ضمنيًا أن قيمة oldValue خالية. يجب أن تكون "n"

تتوقع جميع حالات الاختبار في هذا الملف أن تكون مساحة اسم السمة فارغة (كائن) ، ويجب أن تكون DOMString خالية وفقًا للمواصفات.

نوع attributeNamespace هو DOMString ؟، لذلك يُسمح أن يكون فارغًا (ليس "فارغًا" ، فقط فارغ).

نشكرك على توضيح حالة oldValue :).

حسنًا ، شكرًا للتوضيح - أعتقد أنني فاتني جوانب مهمة من المواصفات.

لقد أضفت فرع MutationObserver في مفترقتي وقمت بدفعه إليه. حاليًا ، اجتازت طفرات السمات وبيانات الأحرف أهم اختبارات w3c.

أين أقوم بتوثيق الاختبارات التي لم تنجح لأسباب / مشاكل معروفة (دعم النطاق مفقود # 317 وما إلى ذلك)؟

ما نفعله هو إضافتها إلى ملف index.js لاختبارات منصة الويب ، لكننا علقنا عليها ، مع تعليق على السبب. انظر على سبيل المثال ما نفعله للقالب .

هل هذا أبعد ما يكون عن الانتهاء؟

يبدو أنه تمت إزالة أحداث الطفرة في 8.5 . هل هناك أي طريقة لاختبار العناصر المخصصة (تتطلب مراقبات الطفرات) دون الرجوع إلى 8.5 والاعتماد على polyfill؟ لم يتم تنفيذ DOMParser في 8.5 وأطلب ذلك من أجل Shadow DOM polyfill لذلك نحن محظورون نوعًا ما من خلال قدرتنا على تشغيل الاختبارات في JSDOM في الوقت الحالي. أي إرشادات ستكون مفيدة هنا. ليس لدي القدرة في الوقت الحالي على محاولة الغوص والمساعدة في تنفيذ هذا الآن ، لسوء الحظ.

لست على علم بأي طريقة للقيام بذلك ، آسف :(.

هل يمكنني المساعدة في تحريك هذا؟ يبدو أن بعض الأعمال قد بدأت هنا: https://github.com/henrikkorsgaard/jsdom/commits/MutationObserver

لكني لست متأكدًا مما لا يزال مطلوبًا لتحريك هذا الأمر. يبدو أن هناك فجوة كبيرة لعدم وجود هذا نظرًا لأن MutationObserver يتم دعمه بشكل أساسي في كل مكان: http://caniuse.com/#feat = mutationobserver

هل يمكننا الاستفادة من webcomponentsjs polyfill؟ https://github.com/webcomponents/webcomponentsjs

طلب السحب هو دائما موضع ترحيب. إن عملhenrikkorsgaard بالتأكيد مكان جيد للبدء. لا أعتقد أن polyfill منطقي رغم ذلك.

مما يمكنني قوله ، تمت إزالة أحداث الطفرة بسبب اعتبارات الأداء ؛ نفس سبب تحديد Mutation Observer وتنفيذه بواسطة المتصفحات. ومع ذلك ، احتفظت المتصفحات بهذه الوظيفة على الأقل حتى تم تنفيذ دعم MO. قد يكون النهج العملي هنا هو إعادة إضافة الدعم لذلك ، على الأقل ، يمكن تعبئة MOs حتى يتم تنفيذ ذلك. أدرك أنها ليست مثالية لصيانة JSDOM وقد تباعدت قاعدة الشفرة منذ ذلك الحين. ومع ذلك ، أعتقد أن الأمر يستحق النظر. هذا يترك فجوة كبيرة ، خاصة في هذه المرحلة حيث تكون مكونات الويب حلاً قابلاً للتطبيق لتطبيقات الإنتاج وتتطلب MO ليتم تعبئتها. سيكون من الجيد أن تكون قادرًا على إجراء الاختبارات في JSDOM.

إذا كان يساعد أنا مملوءة بولي على القمة jsdom ؛ هنا وهنا . لن أقول إنه حل جيد ، لكنه يعمل وبدون مؤقتات أيضًا.

منذ 4 سنوات وما زالت جارية؟ تم ذكر هذه المشكلة في سجل التغيير منذ الإصدار 9.0.0 . هل لديكم أي أخبار عن هذا يا رفاق؟

MeirionHughes الملف يعمل بسلاسة ، شكرًا!

أي تعديل حدث في هذه القضية؟

https://twitter.com/slicknet/status/782274190451671040

مجرد امتداد لرابطdomenic :
حاول وضع هذا الملف الذي اقترحه MeirionHughes ، لقد عمل بشكل جيد حتى الآن.

mtrabelsiMeirionHughes مرحبا، أنا لم يتمكن من العمل على انجاحه في الدعابة، وأنا حصلت على هذا الخطأ https://stackoverflow.com/questions/43190171/jsdom-cannot-read-property-location-of-null
هل يمكن أن تشرح كيف تمكنت من استخدام MO في JSDOM؟

تعديل:
حسنًا ، يبدو أنني تمكنت من جعله يعمل https://gist.github.com/romuleald/1b9272fce11d344e257d0bdfd3a984b0

romuleald هناك خطأ في this.expando و this.counter في المُنشئ ولكن بعد ذلك تقوم بالوصول إليها بشكل ثابت. سيؤدي هذا إلى مشاكل خطيرة في _findMutations . ستلاحظ أنه في الملفات المطبوعة التي كنت تحاول تحويلها ، كانت كلتا الخاصيتين ثابتتين (غير ممكنين مع ES6). أقترح إضافة هذه الأسطر أسفل فئة Util:

Util.counter = 1;
Util.expando = 'mo_id';

وبعد ذلك يمكنك التخلص من المُنشئ تمامًا (لا يتم إنشاء مثيل للفئة على أي حال).

لقد استغرق الأمر وقتًا طويلاً بشكل محرج لاكتشاف هذا لأنني كنت أقوم بتصحيح مشكلة تسببت فيها خلال اليوم ونصف اليوم الماضيين.

بالإضافة إلى ذلك، المصدر الذي يستند الرقاقة على لا يدعم تغييرات على .data ممتلكات CharacterData العقد. يمكنك رؤية مشكلتي المرتبطة أعلى هذا التعليق لإصلاح بسيط.

لقد تمكنت من اختبار ذلك باستخدام https://github.com/megawac/MutationObserver.js polyfill في الوقت الحالي.

أنا استخدم AVA. و 'm' هي الوحدة النمطية الخاصة بي التي تحتوي على MutationObserver.

import test from 'ava';
import delay from 'delay';
import jsdom from 'jsdom';
import m from '.';

const dom = new jsdom.JSDOM();
global.window = dom.window;
global.document = dom.window.document;

require('mutationobserver-shim');

global.MutationObserver = window.MutationObserver;

test('MutationObserver test', async t => {
    delay(500).then(() => {
        const el = document.createElement('div');
        el.id = 'late';
        document.body.appendChild(el);
    });

    const checkEl = await m('#late');
    t.is(checkEl.id, 'late');
});

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

هناك طريقة أخرى لاستخدامها على أنها polyfill مع jsdom و jest وهي تحميل الرقاقة كنص يدويًا.

npm install mutationobserver-shim

وعلى سبيل المثال داخل وظيفة beforeAll:

const mo = fs.readFileSync(
  path.resolve('node_modules', 'mutationobserver-shim', 'dist', 'mutationobserver.min.js'),
  { encoding: 'utf-8' },
);
const moScript = win.document.createElement('script');
moScript.textContent = mo;

win.document.body.appendChild(moScript);

هذا "الاختراق" يناسبني ، وربما للآخرين أيضًا ؛)

وجدت IIRC أنه يعمل جيدًا لتحميل الرقاقة (لقد استخدمت نسخة معدلة من الكود من pal-nodejs ، ولست متأكدًا مما تستند إليه حزمة npm أعلاه) كجزء من setupFiles for Jest. يمكنني تقديم معلومات أكثر تحديدًا بمجرد وصولي إلى الكمبيوتر المحمول الآخر إذا كان أي شخص مهتمًا.

لذلك كان هذا مفتوحًا منذ ما يقرب من 5 سنوات ، هل هناك أي تحديثات للحالة؟

https://twitter.com/slicknet/status/782274190451671040

mendrik يسخر من الأمر بالنسبة لي https://github.com/benitogf/corsarial/blob/master/test/specs/utils.js#L29 وكما ذكر أعلاه ، هناك أيضًا حل

لدينا تنفيذ جزئي هنا: https://github.com/skatejs/skatejs/blob/master/packages/ssr/register/MutationObserver.js.

benitogf لقد حاولت ذلك ولكن بطريقة ما السجلات لم تنطلق من أجلي :(
@ treshugart كيف يمكنني استخدام ذلك؟ :)

mendrik في اختباراتك ، قم باستيراد هذا https://github.com/aurelia/pal-nodejs/blob/master/src/polyfills/mutation-observer.ts
وضبطه على المتغير الشامل. هذا هو!

mendrik إذا كنت على استعداد https://github.com/skatejs/skatejs/tree/master/packages/ssr#usage. إذا لم يكن الأمر كذلك ، فيمكنك استيراد هذا الملف مباشرةً وإضافة عمليات التصدير (https://github.com/skatejs/skatejs/blob/master/packages/ssr/register/MutationObserver.js#L109) إلى ملفك العالمي.

كان هذا كافيًا لإصلاح هذه المشكلة بالنسبة لي أثناء محاولتي اختبار المكون الذي يعمل على تمديد رد الفعل:

import 'mutationobserver-shim';

document.getSelection = () => null;