Cette page a été traduite par l'API Cloud Translation.

ReportingObserver: connaître l'état de votre code

Philip Walton

Résumé

Il y a un nouvel observateur en ville ! ReportingObserver est une nouvelle API qui vous permet de savoir 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 backend ou à un fournisseur d'analyse en vue d'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 qu'en tant que messages de la console. Les interventions, en particulier, ne sont déclenchées que par diverses contraintes du monde réel, telles que les conditions liées à l'appareil et au réseau. Il est donc possible que vous ne voyiez même jamais ces messages lorsque vous développez/testez un site en local. ReportingObserver fournit la solution à ce problème. Lorsque des utilisateurs rencontrent des problèmes potentiels, nous pouvons en être informés.

Remarque:ReportingObserver n'est expédié que dans Chrome 69. D'autres navigateurs l'envisagent.

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 ce qui se passe dans une application Web. Par exemple, il existe des API qui peuvent observer des informations sur le DOM: ResizeObserver, IntersectionObserver et MutationObserver. Il existe des API permettant d'enregistrer les mesures des performances: PerformanceObserver. D'autres API telles que window.onerror et window.onunhandledrejection nous informent même en cas de problème.

Cependant, d'autres types d'avertissements ne sont pas détecté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 vous en informent en premier:

Avertissements relatifs aux abandons et aux interventions dans la console DevTools. — Avertissements déclenchés par le navigateur dans la console des outils de développement

On pourrait naturellement penser 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 en cas d'erreurs d'exécution (exceptions JavaScript et erreurs de syntaxe) causées par l'exécution de votre code.

ReportingObserver prend le relais. Elle permet d'être informé par programmation des avertissements émis par le navigateur, tels que les abandons et les interventions. Vous pouvez l'utiliser comme outil de signalement et perdre moins de temps à vous demander si les utilisateurs rencontrent des problèmes inattendus sur votre site en ligne.

Terme clé:ReportingObserver fait partie d'une spécification plus large, l'API Reporting, qui fournit un moyen commun d'envoyer ces différents rapports à un backend. L'API Reporting est essentiellement un framework générique permettant de spécifier un ensemble de points de terminaison de serveur auxquels signaler les problèmes.

L'API

Cette API est semblable aux autres API "observer", telles que IntersectionObserver et ResizeObserver. Vous lui rappelez ; cela vous donne des informations. Les informations reçues par le rappel sont une 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']});

Terme clé:il existe actuellement deux types de rapports: 'deprecation' et 'intervention'.

Rapports mis en mémoire tampon

L'option buffered: true est vraiment 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});

Elle est idéale pour les situations telles que le chargement différé d'une bibliothèque utilisant un ReportingObserver. L'observateur est ajouté tard, mais vous ne ratez rien de ce qui s'est passé au début du chargement de la page.

Arrêter l'observation

Oui. Il dispose d'une méthode disconnect:

observer.disconnect(); // Stop the observer from collecting reports.

Exemples

Exemple – Signaler 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 – Recevez une notification lorsque des API vont être 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 d'identifier et de surveiller les problèmes potentiels de 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, prenez connaissance des problèmes concrets rencontrés par les utilisateurs sur votre site, mettez à jour le code, et réalisez vos bénéfices !

Travaux futurs

À l'avenir, j'espère que ReportingObserver deviendra l'API de facto permettant de détecter tous les types de problèmes en JavaScript. Imaginez une API pour détecter tout ce qui ne va pas dans votre application:

Interventions au niveau du navigateur
Abandons
un non-respect des Règles relatives aux fonctionnalités. Consultez crbug.com/867471.
Exceptions et erreurs JS (actuellement traitées par window.onerror).
Refus des promesses JS non gérées (actuellement traitées par window.onunhandledrejection)

J'ai également hâte que les outils intègrent ReportingObserver à leurs workflows. Lighthouse est un exemple d'outil qui signale déjà les abandons de navigateurs lorsque vous exécutez son audit Évite les API obsolètes:

L'audit Lighthouse concernant l'utilisation d'API obsolètes peut utiliser ReportingObserver. — L'audit Lighthouse concernant l'utilisation d'API obsolètes pourrait utiliser ReportingObserver.

Lighthouse utilise actuellement le protocole DevTools pour récupérer les messages de la console et signaler ces problèmes aux développeurs. À la place, il peut être intéressant de passer à ReportingObserver pour ses rapports d'obsolescence bien structurés et ses métadonnées supplémentaires telles que la date anticipatedRemoval.

Autres ressources: