ReportingObserver: Codezustand ermitteln

Philip Walton

Kurzfassung

Es gibt einen neuen Beobachter in der Stadt! ReportingObserver ist eine neue API, die dich darüber informiert, wenn auf deiner Website eine eingestellte API verwendet wird oder eine Browseraktion ausgeführt 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 Konsolenmeldungen verfügbar. Insbesondere werden nur durch verschiedene reale Einschränkungen wie Geräte- und Netzwerkbedingungen ausgelöst. Daher sehen Sie diese Meldungen eventuell gar nicht, wenn Sie eine Website lokal entwickeln oder testen. ReportingObserver bietet die Lösung für dieses Problem. Wir werden über potenzielle Probleme informiert.

Einleitung

Vor einiger Zeit habe ich einen Blogpost („Beobachtung Ihrer Webanwendung“) verfasst. Es war faszinierend, wie viele APIs zum Überwachen der „Inhalte“ in einer Webanwendung vorhanden sind. So gibt es beispielsweise APIs, die Informationen zum DOM erfassen: ResizeObserver, IntersectionObserver, MutationObserver. Es gibt APIs zum Erfassen von Leistungsmessungen: PerformanceObserver. Andere APIs wie window.onerror und window.onunhandledrejection teilen uns sogar mit, wenn ein Fehler auftritt.

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 der Entwicklertools-Konsole bezüglich Einstellung und Eingriffen.
Vom Browser initiierte Warnungen in der Entwicklertools-Konsole.

Man könnte natürlich denken, 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 werden. Es wird bei Laufzeitfehlern (JS-Ausnahmen und Syntaxfehlern) ausgelöst, die durch die Ausführung Ihres Codes verursacht wurden.

ReportingObserver erkennt das Spiel. Sie bietet eine programmatische Möglichkeit, über vom Browser ausgegebene Warnungen wie Einstellungen und Eingriffe benachrichtigt zu werden. Du kannst es als Berichtstool verwenden, damit du dich nicht mehr fragen kannst, ob bei Nutzern unerwartete Probleme auf deiner Live-Website auftreten.

Mit der API

Die API unterscheidet sich nicht von den anderen Beobachter-APIs wie IntersectionObserver und ResizeObserver. Sie rufen es zurück und erhalten Informationen. Die Informationen, die der Callback erhält, sind eine Liste der Probleme, die von der 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

Berichte können so gefiltert werden, dass nur bestimmte Berichtstypen berücksichtigt werden:

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

Gepufferte Berichte

Die Option buffered: true ist sehr nützlich, wenn Sie Berichte aufrufen möchten, die vor der Erstellung 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 spät hinzugefügt, aber Sie verpassen nichts, was früher beim Seitenaufbau 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, informieren Sie sich über die realen Probleme, auf die Nutzer auf Ihrer Website stoßen, aktualisieren Sie den Code, aktualisieren Sie den Gewinn!

Zukünftige Arbeiten

Ich hoffe, dass ReportingObserver in Zukunft zur De-facto-API wird, mit der alle Arten von Problemen in JS erkannt werden können. Stellen Sie sich eine API vor, mit der Sie alles erfassen können, was in Ihrer App schiefgeht:

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

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

Bei der Lighthouse-Prüfung für die Verwendung eingestellter APIs könnte ReportingObserver verwendet werden.
Für die Lighthouse-Prüfung für die Verwendung eingestellter APIs könnte ReportingObserver verwendet werden.

Lighthouse verwendet derzeit das DevTools-Protokoll, um Konsolennachrichten zu extrahieren und diese Probleme an Entwickler zu melden. Stattdessen könnte es interessant sein, zu ReportingObserver zu wechseln, da die Berichte zu Einstellungen und zusätzliche Metadaten wie das anticipatedRemoval-Datum übersichtlich strukturiert sind.

Weitere Informationen: