ReportingMonitorer: تعرّف على حالة الرمز البرمجي

Philip Walton

TL;DR

هناك مراقب جديد في المدينة. ReportingObserver هي واجهة برمجة تطبيقات جديدة تتيح لك معرفة متى يستخدم موقعك الإلكتروني واجهة برمجة تطبيقات متوقّفة نهائيًا أو يتعرَّض التأثير في المتصفّح:

const observer = new ReportingObserver(
  (reports, observer) => {
    for (const report of reports) {
      console.log(report.type, report.url, report.body);
    }
  },
  {buffered: true}
);

observer.observe();

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

لماذا يعتبر ذلك مفيدًا؟ حتى الآن، لم تكن تحذيرات التدخل تظهر إلا في "أدوات مطوري البرامج" كرسائل على وحدة التحكم. لا تتم التدخلات، على وجه الخصوص، إلا من خلال قيود مختلفة في العالم الحقيقي مثل ظروف الجهاز والشبكة. لذلك، قد لا تظهر لك هذه الرسائل مطلقًا عند تطوير/اختبار موقع محليًا. يوفّر ReportingObserver حل هذه المشكلة. عندما يواجه المستخدمون مشكلات محتملة في البرية، يمكننا إبلاغنا بها.

مقدمة

وكتبتُ منذ فترة مشاركة مدونة ("تتبُّع تطبيق الويب الخاص بك"). لأنني وجدت أنه عدد رائع من واجهات برمجة التطبيقات لمراقبة "أشياء" يحدث في تطبيق الويب. فعلى سبيل المثال، هناك واجهات برمجة تطبيقات يمكنها مراقبة معلومات حول DOM: ResizeObserver، IntersectionObserver، MutationObserver. توجد واجهات برمجة تطبيقات لالتقاط قياسات الأداء: PerformanceObserver. مشاكل أخرى حتى أن واجهات برمجة التطبيقات مثل window.onerror وwindow.onunhandledrejection تخبرنا بذلك عندما يحدث خطأ ما.

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

قد يعتقد المرء أنّ window.onerror يرصد هذه التحذيرات بشكل طبيعي. الإجابة هي أنّه لا يتعامل معها. يرجع ذلك إلى أنّ window.onerror لا يتم تنشيطه لعرض التحذيرات. يتم إنشاؤه مباشرةً بواسطة وكيل المستخدم نفسه. يتم تنشيطه بسبب أخطاء وقت التشغيل (استثناءات JavaScript وأخطاء الصيغة) الناتجة عن تنفيذ الرمز البرمجي الخاص بك.

يحافظ "ReportingObserver" على فترة الراحة. توفر طريقة آلية تم إرسال إشعارات إلى التحذيرات الصادرة عن المتصفِّح، مثل عمليات الإيقاف النهائي والتدخلات يمكنك استخدامه كأداة إبلاغ تقليل وقت النوم الذي يتساءل عما إذا كان المستخدمون يواجهون مشاكل غير متوقعة في البث المباشر موقعك.

واجهة برمجة التطبيقات

لا تختلف واجهة برمجة التطبيقات عن "المراقب" الآخر واجهات برمجة التطبيقات مثل باسم IntersectionObserver وResizeObserver تعيد الاتصال به؛ وتمنحك المعلومات. والمعلومات التي يتلقّاها معاودة الاتصال هي قائمة بالمشاكل التي تسببت فيها الصفحة:

const observer = new ReportingObserver((reports, observer) => {
  for (const report of reports) {
    // → report.type === 'deprecation'
    // → report.url === 'https://reporting-observer-api-demo.glitch.me'
    // → report.body.id === 'XMLHttpRequestSynchronousInNonWorkerOutsideBeforeUnload'
    // → report.body.message === 'Synchronous XMLHttpRequest is deprecated...'
    // → report.body.lineNumber === 11
    // → report.body.columnNumber === 22
    // → report.body.sourceFile === 'https://reporting-observer-api-demo.glitch.me'
    // → report.body.anticipatedRemoval === <JS_DATE_STR> or null
  }
});

observer.observe();

التقارير التي تمت فلترتها

يمكن فلترة التقارير مسبقًا لمراقبة أنواع معيّنة فقط من التقارير:

const observer = new ReportingObserver((reports, observer) => {
  ...
}, {types: ['deprecation']});

التقارير المخزَّنة مؤقتًا

يكون الخيار buffered: true مفيدًا حقًا عندما تريد الاطّلاع على التقارير التي تم إنشاؤها قبل إنشاء المراقب:

const observer = new ReportingObserver((reports, observer) => {
  ...
}, {types: ['intervention'], buffered: true});

وهو مثالي في حالات مثل التحميل الكسول لمكتبة تستخدم ReportingObserver تتم إضافة المراقب في وقت متأخر، لكنك عدم تفويت أي معلومات حدثت في وقت سابق أثناء تحميل الصفحة.

إيقاف الملاحظة

إجابة صحيحة. يتم اتّباع طريقة disconnect:

observer.disconnect(); // Stop the observer from collecting reports.

أمثلة

مثال: إبلاغ أحد مزودي التحليلات عن تدخلات المتصفح:

const observer = new ReportingObserver(
  (reports, observer) => {
    for (const report of reports) {
      sendReportToAnalytics(JSON.stringify(report.body));
    }
  },
  {types: ['intervention'], buffered: true}
);

observer.observe();

مثال: لتلقّي إشعار عند إزالة واجهات برمجة التطبيقات:

const observer = new ReportingObserver((reports, observer) => {
  for (const report of reports) {
    if (report.type === 'deprecation') {
      sendToBackend(`Using a deprecated API in ${report.body.sourceFile} which will be
                     removed on ${report.body.anticipatedRemoval}. Info: ${report.body.message}`);
    }
  }
});

observer.observe();

الخاتمة

يتيح لك "ReportingObserver" طريقة إضافية لاستكشاف المحتوى ومراقبته. المشكلات المحتملة في تطبيق الويب. إنها حتى أداة مفيدة لفهم حالة قاعدة التعليمات البرمجية (أو عدم وجودها). إرسال التقارير إلى الواجهة الخلفية المشاكل الواقعية التي يواجهها المستخدمون في موقعك الإلكتروني الرمز، الربح!

العمل المستقبلي

آمل أن تصبح واجهة برمجة التطبيقات ReportingObserver هي السياسة الفعلية في المستقبل. لاكتشاف جميع أنواع المشكلات في JavaScript. تخيل أن واجهة برمجة تطبيقات واحدة يمكنها التعرف على كل شيء الذي يحدث بشكل خاطئ في تطبيقك:

• تدخلات المتصفِّح
• عمليات الإيقاف نهائيًا
• انتهاكات سياسة الميزات: لمزيد من المعلومات، يُرجى الانتقال إلى crbug.com/867471.
• استثناءات وأخطاء JavaScript (تتم الخدمة حاليًا من قِبل "window.onerror")
• حالات رفض وعود JS التي لم تتم معالجتها (تتم الخدمة حاليًا من قِبل window.onunhandledrejection)

أنا متحمس أيضًا بشأن الأدوات التي تدمج ReportingObserver في وسير أعمالهم. إنّ Lighthouse هي مثال على إحدى الأدوات تُبلِغ عن الإيقاف النهائي للمتصفّح عندما تشغّل "تجنُّب واجهات برمجة التطبيقات المتوقّفة نهائيًا" التدقيق:

تستخدم أداة Lighthouse حاليًا بروتوكول أدوات مطوّري البرامج لسرقة رسائل وحدة التحكم وإبلاغ المطورين بهذه المشكلات. بدلاً من ذلك، قد يكون من المثير للاهتمام التبديل إلى ReportingObserver بفضل تقارير الإيقاف النهائي المنظَّمة بشكل جيد والبيانات الوصفية الإضافية مثل التاريخ: anticipatedRemoval

مراجع إضافية:

• مواصفات W3c
• إدخال chromestatus.com