ReportingObserver: Codezustand ermitteln

Kurzfassung

Es gibt einen neuen Beobachter in der Stadt! ReportingObserver ist eine neue API, mit der Sie wenn Ihre Website eine veraltete API verwendet oder eine Eingriff des Browsers:

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 Callback können Berichte an ein Backend oder einen Analyseanbieter gesendet werden. zur weiteren Analyse an.

Warum ist das nützlich? Bisher waren Einstellung und Interventionswarnungen waren in den Entwicklertools nur als Konsolenmeldungen verfügbar. Vor allem werden Eingriffe nur durch verschiedene reale Einschränkungen ausgelöst. wie Geräte- und Netzwerkbedingungen. Daher sehen Sie diese Nachrichten wenn Sie eine Website lokal entwickeln oder testen. ReportingObserver bietet die Lösung für dieses Problem. Wenn Nutzende potenzielle Probleme stoßen, können wir darüber benachrichtigt werden.

Einführung

Vor einiger Zeit habe ich den Blogpost Beobachtung deiner Web-App veröffentlicht. Es war faszinierend, wie viele APIs es gibt, „Dinge“ in einer Webanwendung. Es gibt z. B. APIs, die Daten Informationen zum DOM: ResizeObserver, IntersectionObserver, MutationObserver. Es gibt APIs zum Erfassen Leistungsmessungen: PerformanceObserver. Sonstiges APIs wie window.onerror und window.onunhandledrejection teilen uns sogar wenn etwas schiefgeht.

Es gibt jedoch auch andere Arten von Warnungen, die von diesen vorhandenen APIs. Wenn Ihre Website eine eingestellte API verwendet oder ausgeführt wird Browserintervention verhindern, sollten Sie in den Entwicklertools zuerst über sie:

<ph type="x-smartling-placeholder">
</ph> Warnungen der Entwicklertools-Konsole bezüglich Einstellung und Eingriffen.
Vom Browser ausgelöste 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 bei Warnungen nicht ausgelöst wird die direkt vom User-Agent generiert werden. Wird bei Laufzeitfehlern ausgelöst (JS-Ausnahmen und Syntaxfehler), die durch die Ausführung Ihres Codes verursacht wurden.

ReportingObserver erkennt das Spiel. Es bietet eine programmatische Möglichkeit, werden über vom Browser ausgegebene Warnungen wie Einstellung von Produkten und Diensten informiert und Maßnahmen. Sie können es als Berichtstool verwenden und weniger Schlaf, weil sich Nutzer fragen, ob bei einem Livestream unerwartete Probleme auftreten. Website.

Mit der API

Das API unterscheidet sich nicht von dem APIs wie als IntersectionObserver und ResizeObserver. Sie rufen ihn zurück, erhalten Sie Informationen. Die Informationen, die der Rückruf erhält, Liste der von der Seite verursachten Probleme:

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, die vor der Erstellung des Beobachters generiert wurden:

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

Sie eignet sich hervorragend für das Lazy Loading einer Bibliothek, ReportingObserver. Der Beobachter kommt zu spät hinzu, aber Sie Lassen Sie sich beim Seitenaufbau nichts entgehen.

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 dir eine zusätzliche Möglichkeit, Daten zu ermitteln und zu überwachen mögliche Probleme in Ihrer Webanwendung. Es ist sogar ein nützliches Tool, um die Status Ihrer Codebasis (oder fehlender Codebasis) besteht. Senden Sie Berichte an ein Backend, über die Probleme, auf die Nutzer auf Ihrer Website stoßen, Code, Profit!

Zukünftige Arbeiten

Ich hoffe, dass ReportingObserver in Zukunft zur De-facto-API wird. zur Erkennung aller Arten von Problemen in JS. Stellen Sie sich eine API vor, um alles zu erfassen die 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 (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 zu verbessern. Lighthouse ist ein Beispiel für ein die bereits eingestellte Browser anzeigt, Vermeidet eingestellte APIs Prüfung:

<ph type="x-smartling-placeholder">
</ph> Bei der Lighthouse-Prüfung für die Verwendung eingestellter APIs könnte ReportingObserver verwendet werden.
Bei der Lighthouse-Prüfung für die Verwendung eingestellter APIs könnte ReportingObserver verwendet werden.

Lighthouse verwendet derzeit das DevTools-Protokoll. um Konsolennachrichten auszulesen und diese Probleme an die Entwickler zu melden. Stattdessen werden sie könnte interessant sein, zu ReportingObserver zu wechseln dank der gut strukturierten Berichte zu Einstellungen und zusätzlichen Metadaten wie anticipatedRemoval Datum.

Weitere Informationen: