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:
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:
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: