Résumé
Un nouvel observateur est en ville ! ReportingObserver est une nouvelle API qui vous indique quand votre site utilise une API obsolète ou subit une intervention du navigateur:
const observer = new ReportingObserver(
(reports, observer) => {
for (const report of reports) {
console.log(report.type, report.url, report.body);
}
},
{buffered: true}
);
observer.observe();
Le rappel peut être utilisé pour envoyer des rapports à un fournisseur de backend ou d'analyse pour une analyse plus approfondie.
En quoi est-ce utile ? Jusqu'à présent, les avertissements d'abandon et d'intervention n'étaient disponibles dans les outils de développement que sous forme de messages de console.
Les interventions, en particulier, ne sont déclenchées que par différentes contraintes du monde réel, telles que les conditions de l'appareil et du réseau. Ainsi, vous pourriez ne jamais voir ces messages lorsque vous développez/testez un site en local. ReportingObserver fournit la solution à ce problème. Lorsque les utilisateurs rencontrent des problèmes potentiels dans la nature, nous pouvons en être informés.
Introduction
Il y a quelque temps, j'ai rédigé un article de blog ("Observer votre application Web"), car j'ai trouvé fascinant le nombre d'API permettant de surveiller le "contenu" d'une application Web. Par exemple, certaines API peuvent observer des informations sur le DOM: ResizeObserver, IntersectionObserver et MutationObserver. Il existe des API permettant de capturer les mesures des performances: PerformanceObserver. D'autres API, telles que window.onerror et window.onunhandledrejection, nous signalent même en cas de problème.
Toutefois, il existe d'autres types d'avertissements qui ne sont pas capturés par ces API existantes. Lorsque votre site utilise une API obsolète ou s'exécute suite à une intervention du navigateur, les outils de développement doivent d'abord vous en informer:
On pense naturellement que window.onerror capture ces avertissements. Ce n'est pas le cas.
En effet, window.onerror ne se déclenche pas pour les avertissements générés directement par le user-agent lui-même. Il se déclenche pour les erreurs d'exécution (exceptions JavaScript et erreurs de syntaxe) causées par l'exécution de votre code.
ReportingObserver place le jeu. Elle offre un moyen programmatique d'être averti des avertissements émis par les navigateurs, tels que des abandons et des interventions. Vous pouvez l'utiliser comme un outil de reporting et perdre moins de sommeil en vous demandant si les utilisateurs rencontrent des problèmes inattendus sur votre site en ligne.
L'API
L'API ressemble aux autres API "observateurs", telles que IntersectionObserver et ResizeObserver. Vous lui rappelez
et vous obtenez des informations. Les informations reçues par le rappel sont la liste des problèmes causés par la page:
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();
Rapports filtrés
Vous pouvez préfiltrer les rapports pour n'observer que certains types de rapports:
const observer = new ReportingObserver((reports, observer) => {
...
}, {types: ['deprecation']});
Rapports mis en mémoire tampon
L'option buffered: true est très utile lorsque vous souhaitez afficher les rapports générés avant la création de l'observateur:
const observer = new ReportingObserver((reports, observer) => {
...
}, {types: ['intervention'], buffered: true});
Il est idéal pour des situations telles que le chargement différé d'une bibliothèque qui utilise un ReportingObserver. L'observateur est ajouté tardivement, mais vous ne manquez rien de ce qui s'est passé plus tôt dans le chargement de la page.
Arrêter l'observation
Oui. Elle utilise une méthode disconnect:
observer.disconnect(); // Stop the observer from collecting reports.
Exemples
Exemple – Transmettre les interventions du navigateur à un fournisseur de solutions d'analyse:
const observer = new ReportingObserver(
(reports, observer) => {
for (const report of reports) {
sendReportToAnalytics(JSON.stringify(report.body));
}
},
{types: ['intervention'], buffered: true}
);
observer.observe();
Exemple pour être averti lorsque des API seront supprimées:
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();
Conclusion
ReportingObserver vous offre un moyen supplémentaire de découvrir et de surveiller les problèmes potentiels dans votre application Web. Il s'agit même d'un outil utile pour comprendre l'état de votre codebase (ou son absence). Envoyez des rapports à un backend, informez-vous sur les problèmes concrets que les utilisateurs rencontrent sur votre site, mettez à jour votre code, gagnez en efficacité !
Travaux futurs
À l'avenir, j'espère que ReportingObserver deviendra l'API de facto permettant d'identifier tous les types de problèmes dans JS. Imaginez une API capable de détecter tous les problèmes dans votre application:
- Interventions via le navigateur
- Abandons
- Non-respect des Règles relatives aux fonctionnalités. Consultez la page crbug.com/867471.
- Exceptions et erreurs JS (actuellement gérés par
window.onerror). - Refus de promesses JS non gérés (actuellement gérés par
window.onunhandledrejection)
Je suis également intéressé par les outils qui intègrent ReportingObserver dans leurs workflows. Lighthouse est un exemple d'outil qui signale déjà les abandons de navigateurs lorsque vous exécutez son audit Éviter les API obsolètes:
Lighthouse utilise actuellement le protocole DevTools pour récupérer les messages de la console et signaler ces problèmes aux développeurs. Il peut être intéressant de passer à ReportingObserver pour ses rapports d'abandon bien structurés et ses métadonnées supplémentaires telles que la date anticipatedRemoval.
Autres ressources