ReportingObserver: Codezustand ermitteln

Kurzfassung

Es gibt einen neuen Beobachter! ReportingObserver ist eine neue API, mit der Sie erkennen können, ob auf Ihrer Website eine eingestellte API verwendet wird oder eine Browser-Intervention auftritt:

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

observer.observe();

Über den Rückruf können Berichte zur weiteren Analyse an einen Backend- oder Analyseanbieter gesendet werden.

Warum ist das hilfreich? Bisher waren Warnungen zur Einstellung und zu Interventionen nur in den DevTools als Konsolennachrichten verfügbar. Insbesondere werden nur durch verschiedene reale Einschränkungen wie Geräte- und Netzwerkbedingungen ausgelöst. Daher sehen Sie diese Meldungen möglicherweise nie, wenn Sie eine Website lokal entwickeln oder testen. ReportingObserver bietet die Lösung für dieses Problem. Wenn Nutzer in der Praxis auf potenzielle Probleme stoßen, können wir darüber informiert werden.

Einführung

Vor einiger Zeit habe ich einen Blogpost mit dem Titel Observing your web app (Ihre Webanwendung beobachten) geschrieben, weil ich es faszinierend fand, wie viele APIs es zum Überwachen der Vorgänge in einer Webanwendung gibt. Es gibt beispielsweise APIs, die Informationen zum DOM erfassen können: ResizeObserver, IntersectionObserver und MutationObserver. Es gibt APIs für die Erfassung von Leistungsmesswerten: PerformanceObserver. Andere APIs wie window.onerror und window.onunhandledrejection informieren uns sogar, wenn etwas schiefgeht.

Es gibt jedoch andere Arten von Warnungen, die von diesen APIs nicht erfasst werden. Wenn Ihre Website eine eingestellte API verwendet oder für eine Browsereingriffe ausgeführt wird, werden Sie von den Entwicklertools zuerst darüber informiert:

Warnungen in der Entwicklertools-Konsole zu eingestellten Funktionen und Maßnahmen
Browser-initiierte Warnungen in der Entwicklertools-Konsole

Man könnte natürlich denken, dass window.onerror diese Warnungen erfasst. Nein. Das liegt daran, dass window.onerror nicht für Warnungen ausgelöst wird, die direkt vom User-Agent selbst generiert werden. Er wird bei Laufzeitfehlern (JS-Ausnahmen und Syntaxfehlern) ausgelöst, die durch die Ausführung Ihres Codes verursacht werden.

ReportingObserver erkennt das Spiel. Sie bietet eine programmatische Möglichkeit, über von Browsern ausgegebene Warnungen wie Einschränkungen und Eingriffe informiert zu werden. Sie können es als Meldetool verwenden und sich weniger Sorgen machen, ob Nutzer auf Ihrer Live-Website auf unerwartete Probleme stoßen.

Mit der API

Die API ähnelt anderen „Observer“-APIs wie IntersectionObserver und ResizeObserver. Sie rufen es zurück und erhalten Informationen. Der Rückruf enthält eine Liste der Probleme, die auf der Seite aufgetreten sind:

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();

Gefilterte Berichte

Berichte können vorab gefiltert werden, damit nur bestimmte Berichtstypen berücksichtigt werden:

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

Zwischengespeicherte Berichte

Die Option buffered: true ist sehr nützlich, wenn Sie die Berichte sehen möchten, die vor dem Erstellen des Beobachters generiert wurden:

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

Sie eignet sich beispielsweise hervorragend für das Lazy Loading einer Bibliothek, die ein ReportingObserver verwendet. Der Beobachter wird erst spät hinzugefügt, aber Sie verpassen nichts, was zuvor beim Laden der Seite passiert ist.

Beobachtung beenden

Ja. Es hat eine disconnect-Methode:

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

Beispiele

Beispiel – Browsermaßnahmen an einen Analyseanbieter melden:

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

observer.observe();

Beispiel: Benachrichtigungen erhalten, wenn APIs entfernt werden:

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();

Fazit

ReportingObserver bietet Ihnen eine zusätzliche Möglichkeit, potenzielle Probleme in Ihrer Webanwendung zu erkennen und zu überwachen. Es ist sogar ein nützliches Tool, um den Zustand Ihrer Codebasis (oder das Fehlen derselben) zu ermitteln. Senden Sie Berichte an ein Backend, erfahren Sie, welche Probleme Nutzer auf Ihrer Website haben, aktualisieren Sie den Code und profitieren Sie davon.

Zukünftige Arbeit

Ich hoffe, dass ReportingObserver in Zukunft die De-facto-API für die Erfassung aller Arten von Problemen in JS wird. Stellen Sie sich eine API vor, mit der Sie alles erfassen können, was in Ihrer App schiefgeht:

  • Browseraktionen
  • Verworfene Produkte/Funktionen
  • Verstöße gegen die Funktionsrichtlinie. Weitere Informationen finden Sie unter crbug.com/867471.
  • JS-Ausnahmen und ‑Fehler (aktuell von window.onerror verarbeitet)
  • Unbehandelte JS-Promise-Ablehnungen (derzeit von window.onunhandledrejection bedient)

Ich freue mich auch auf Tools, die ReportingObserver in ihre Workflows einbinden. Lighthouse ist ein Beispiel für ein Tool, das die Einstellung von Browsern bereits meldet, wenn Sie das Audit „Verworfene APIs vermeiden“ ausführen:

Für die Lighthouse-Prüfung auf die Verwendung veralteter APIs kann ReportingObserver verwendet werden.
Für die Lighthouse-Prüfung zur Verwendung eingestellter APIs kann ReportingObserver verwendet werden.

Lighthouse verwendet derzeit das DevTools-Protokoll, um Konsolennachrichten zu erfassen und diese Probleme an Entwickler zu melden. Stattdessen kann es interessant sein, auf ReportingObserver umzustellen, da diese Funktion gut strukturierte Berichte zur Einstellung und zusätzliche Metadaten wie das anticipatedRemoval-Datum enthält.

Weitere Ressourcen: