ReportingObserver: Codezustand ermitteln

Kurzfassung

Es gibt einen neuen Beobachter in der Stadt! ReportingObserver ist eine neue API, über die du informiert wirst, wenn auf deiner Website eine eingestellte API verwendet wird oder eine Browserintervention ausgelöst wird:

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

observer.observe();

Mit dem Callback können Berichte zur weiteren Analyse an ein Back-End oder einen Analyseanbieter gesendet werden.

Warum ist das nützlich? Bisher waren Einstellungs- und Eingriffswarnungen in den Entwicklertools nur als Konsolennachrichten verfügbar. Insbesondere werden Eingriffe nur durch verschiedene reale Einschränkungen wie Geräte- und Netzwerkbedingungen ausgelöst. Daher werden diese Meldungen möglicherweise nie angezeigt, wenn Sie eine Website lokal entwickeln oder testen. ReportingObserver bietet die Lösung für dieses Problem. Wenn Nutzer potenzielle Probleme entdecken, können wir darüber benachrichtigt werden.

Einführung

Vor einiger Zeit habe ich einen Blogpost ("Web-App beobachten") geschrieben, weil es mich faszinierend fand, wie viele APIs es für das Monitoring der Vorgänge in einer Webanwendung gibt. Beispielsweise gibt es APIs, die Informationen über das DOM erfassen können: ResizeObserver, IntersectionObserver, MutationObserver. Es gibt APIs zum Erfassen von Leistungsmessungen: 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 vorhandenen APIs nicht erfasst werden. Wenn Ihre Website eine eingestellte API verwendet oder ein Browserintervention ausgeführt wird, werden Sie von den Entwicklertools zuerst darüber informiert:

Man könnte davon ausgehen, dass window.onerror diese Warnungen erfasst. Das ist nicht der Fall. Das liegt daran, dass window.onerror nicht bei Warnungen ausgelöst wird, die direkt vom User-Agent selbst generiert wurden. Sie wird bei Laufzeitfehlern (JS-Ausnahmen und Syntaxfehlern) ausgelöst, die durch die Ausführung Ihres Codes verursacht werden.

ReportingObserver nimmt das Spiel auf. Sie bietet eine programmatische Möglichkeit, um über vom Browser ausgegebene Warnungen wie Einstellung und Eingriffe benachrichtigt zu werden. Sie können es als Berichtstool verwenden und haben weniger Schlaf, weil Sie sich fragen müssen, ob Nutzer auf Ihrer Live-Website unerwartete Probleme haben.

Mit der API

Die API unterscheidet sich nicht von den anderen Beobachter-APIs wie IntersectionObserver und ResizeObserver. Sie rufen sie zurück, um Informationen zu erhalten. Die Informationen, die an den Callback gesendet werden, sind eine Liste von Problemen, die durch die Seite verursacht wurden:

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

Sie können Berichte so filtern, dass 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 der Erstellung des Beobachters generiert wurden:

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

Diese Methode eignet sich hervorragend für Lazy Loading einer Bibliothek, die ReportingObserver verwendet. Der Beobachter wird erst später hinzugefügt, aber es verpasst nichts, was früher beim Seitenaufbau passiert ist.

Nicht mehr beobachten

Ja. Es gibt eine disconnect-Methode:

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

Beispiele

Beispiel – Browserinterventionen 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: Lassen Sie sich benachrichtigen, 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 zum Erkennen und Überwachen potenzieller Probleme in Ihrer Webanwendung. Es ist sogar ein nützliches Tool, um den Zustand Ihrer Codebasis (oder das Fehlen dieser) zu verstehen. Senden Sie Berichte an ein Back-End, informieren Sie sich über reale Probleme, mit denen Nutzer auf Ihrer Website stoßen, aktualisieren Sie den Code und erzielen Sie Gewinn!

Zukünftige Arbeiten

Ich hoffe, dass ReportingObserver in Zukunft die De-facto-API zum Erkennen aller Arten von Problemen in JS wird. Stellen Sie sich eine API vor, um alle Fehler in Ihrer Anwendung abzufangen:

• Browserprogramme
• Einstellung von Produkten und Funktionen
• Verstöße gegen die Funktionsrichtlinie. Weitere Informationen finden Sie unter crbug.com/867471.
• JS-Ausnahmen und -Fehler (derzeit von window.onerror bereitgestellt).
• Nicht verarbeitete JS-Promise-Ablehnungen (derzeit bereitgestellt von window.onunhandledrejection)

Außerdem freue ich mich über Tools, die ReportingObserver in ihre Workflows integrieren. Lighthouse ist ein Beispiel für ein Tool, das bei der Ausführung der Prüfung Vermeidet verworfene APIs bereits eingestellte Browserfunktionen meldet:

In Lighthouse wird derzeit das DevTools-Protokoll verwendet, um Konsolennachrichten zu extrahieren und diese Probleme an die Entwickler zu melden. Stattdessen kann es interessant sein, zu ReportingObserver zu wechseln, um die gut strukturierten Einstellungsberichte und zusätzliche Metadaten wie das anticipatedRemoval-Datum zu erhalten.

Weitere Informationen:

• W3C-Spezifikationen
• chromestatus.com-Eintrag