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
dieses Problem zu lösen. 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 verfasst.
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">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 es 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});
Diese Funktion eignet sich hervorragend für
das Lazy Loading einer Bibliothek,
ein 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:
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: