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

الملخّص

هناك مراقب جديد في المدينة. 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).
• حالات رفض طلبات JavaScript غير المعالجة (يتم تقديم الخدمة حاليًا من قِبل window.onunhandledrejection)

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

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

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

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