Материал, перевод которого мы публикуем сегодня, посвящён API

Предположим, у вас имеется важный веб-проект, запущенный пару дней назад. Пользователи, во множестве, уже начали регистрироваться на его сайте. Всем изв��стно, что подобные проекты, для того, чтобы они, упрощённо говоря, приносили бы компаниям деньги, должны работать стабильно. Теперь поразмыслим над тем, что происходит в том случае, если ваш клиент сталкивается с неправильным поведением сайта, причиной которого являются какие-то ошибки, а вы об этом ничего не знаете. Ошибку, о возникновении которой не знает разработчик, он не исправит, она будет проявляться снова и снова, а это, в конечном счёте, негативно скажется на бизнес-целях проекта.
Посетитель сайта, вполне возможно, ничего не знает о веб-разработке, поэтому, когда сайт начинает странно вести себя, он вряд ли заглянет в консоль для того, чтобы попытаться разобраться в проблеме, которая выражается в виде сообщения, начинающегося с
Собственно говоря, посетителей сайта не должны заботить ошибки. Всё, что им нужно — это стабильность, удобство и предсказуемость. Ошибки — это проблема разработчиков, и API
Вот как выглядит работа с
Поговорим о том, как пользоваться этим API.
В браузерах существуют API, предназначенные для перехвата ошибок. Например —
Для того чтобы воспользоваться API
При работе c
Если, при создании объекта
Для того чтобы прекратить наблюдение за отчётами об использовании устаревших возможностей или о вмешательствах браузера в работу кода, можно отключить объект-наблюдатель:
Вот пример использования объекта-наблюдателя
API
Подробности о
Уважаемые читатели! Что вы думаете об API ReportingObserver?

ReportingObserver — механизму, который позволяет узнать об использовании устаревших возможностей, и о том, что в работу кода страницы вмешивается браузер. ReportingObserver является частью этой спецификации W3C.
Зачем это нужно?
Предположим, у вас имеется важный веб-проект, запущенный пару дней назад. Пользователи, во множестве, уже начали регистрироваться на его сайте. Всем изв��стно, что подобные проекты, для того, чтобы они, упрощённо говоря, приносили бы компаниям деньги, должны работать стабильно. Теперь поразмыслим над тем, что происходит в том случае, если ваш клиент сталкивается с неправильным поведением сайта, причиной которого являются какие-то ошибки, а вы об этом ничего не знаете. Ошибку, о возникновении которой не знает разработчик, он не исправит, она будет проявляться снова и снова, а это, в конечном счёте, негативно скажется на бизнес-целях проекта.
Посетитель сайта, вполне возможно, ничего не знает о веб-разработке, поэтому, когда сайт начинает странно вести себя, он вряд ли заглянет в консоль для того, чтобы попытаться разобраться в проблеме, которая выражается в виде сообщения, начинающегося с
[Intervention] или [Deprecation].Собственно говоря, посетителей сайта не должны заботить ошибки. Всё, что им нужно — это стабильность, удобство и предсказуемость. Ошибки — это проблема разработчиков, и API
ReportingObserver существует именно для того, чтобы помочь разработчикам с этой проблемой бороться. Средствами ReportingObserver можно отправлять разработчику отчёты об использовании устаревших API или о вмешательствах в работу станицы браузера. Другие средства для обработки ошибок на подобные вещи не реагируют.Вот как выглядит работа с
ReportingObserver:const observer = new ReportingObserver((reports, observer) => { for (const report of reports) { console.log(report.type, report.url, report.body); } }, { buffered: true }); observer.observe();
Поговорим о том, как пользоваться этим API.
Структура API ReportingObserver
В браузерах существуют API, предназначенные для перехвата ошибок. Например —
window.onerror. Однако window.onerror не отслеживает абсолютно все проблемные ситуации, возникающие в ходе работы страницы. Например, это средство помогает узнать об ошибках времени выполнения, вызываемых исключениями JavaScript или синтаксическими ошибками, имеющимися в коде. Однако если будет выдано уведомление об использовании устаревшей возможности или о вмешательстве браузера, window.onerror на подобное уведомление не отреагирует. Именно в такой ситуации нам и пригодится ReportingObserver.Для того чтобы воспользоваться API
ReportingObserver, нужно создать соответствующий объект-наблюдатель, предоставив ему коллбэк, при вызове которого ему будут передаваться, в виде списка, отчёты о проблемах, возникших на странице. Выше мы уже рассматривали код, необходимый для работы с ReportingObserver. Теперь взглянем на пример того, какие данные поступают в коллбэк:const observer = new ReportingObserver((reports, observer) => { for (const report of reports) { // → report.id === 'XMLHttpRequestSynchronousInNonWorkerOutsideBeforeUnload' // → report.type === 'deprecation' // → report.url === 'https://reporting-observer-api-demo.glitch.me' // → report.body.message === 'Synchronous XMLHttpRequest is deprecated...' } }}); observer.observe();
При работе c
ReportingObserver можно фильтровать отчёты. Например вот конструкция, которая позволяет получать лишь отчёты об использовании устаревших возможностей:const observer = new ReportingObserver((reports, observer) => { ... }, {types: ['deprecation']});
Если, при создании объекта
ReportingObserver, передать ему свойство buffered: true, это даст возможность увидеть отчёты, сгенерированные до создания такого объекта:const observer = new ReportingObserver((reports, observer) => { ... }, {types: ['intervention'], buffered: true});
Для того чтобы прекратить наблюдение за отчётами об использовании устаревших возможностей или о вмешательствах браузера в работу кода, можно отключить объект-наблюдатель:
observer.disconnect();
Пример использования API ReportingObserver
Вот пример использования объекта-наблюдателя
ReportingObserver. Здесь показана схема организации отправки отчёта на сервер:const report = new ReportingObserver((reports, observer) => { for (const report of reports) { const stringifiedReport = JSON.stringify(report.body); // Отправка на сервер sendReport(stringifiedReport); } }, { types: [‘deprecation’], buffered: true });
Итоги
API
ReportingObserver позволяет разработчику расширить диапазон получаемых им сведений об ошибках, возникающих в его проектах при работе с ними реальных пользователей. Этот API имеется в Chrome 69, есть сведения о том, что данная возможность появится в Edge. О том, планируется ли реализовать нечто подобное в Firefox или Safari, пока неизвестно. Подробности о
ReportingObserver можно почитать здесь и здесь.Уважаемые читатели! Что вы думаете об API ReportingObserver?

