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

Philip Walton

الملخّص

هناك مراقب جديد في المدينة. 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 الحل لهذه المشكلة. عندما يواجه المستخدمون مشكلات محتملة في البرية، يمكننا إخطارنا بشأنها.

مقدمة

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

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

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

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

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

تختلف واجهة برمجة التطبيقات هذه عن واجهات برمجة التطبيقات "observer" الأخرى، مثل 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