Repository navigation
Allow for custom reports to be generated & queued #259
Description
Allowing individual execution contexts to construct and send their own reports would allow this API to provide a single, consistent approach for the reporting of important client-side information such as unhandled errors, timing metrics, and usage information.
One API I have in mind for this is loosely based on the Performance API and goes something like:
class Reporter extends EventHandler {
constructor(options?: ReporterOptions);
static report<T extends string>(type: T, options?: ReportOptions): CustomReport;
report(type: T, options?: ReportOptions): CustomReport;
}
interface ReporterOptions {
readonly name?: string;
readonly detail?: any;
}
interface ReportOptions {
readonly detail: any;
readonly timestamp: DomHighResTimeStamp;
}
class CustomReport extends Report {
readonly body: CustomReportBody;
}
class CustomReportBody extends ReportBody {
readonly reporter?: ReporterOptions;
readonly detail?: any;
}An execution context may then initialize a new report as:
Reporter.report('unhandled-error');
// or
const myReporter = new Reporter({name: 'toolbar'});
myReporter.report('item-clicked', {detail: {'item-name': 'Save'}});All custom reports' types would be prefixed with 'custom-' so that they are clearly differentiated from browser-native events. Individual Reporter instances provide additional details about the context of a report.
The "body" of these reports would include a "detail" entry containing the "detail" value from the report as well as a "reporter" entry which contains values from the ReporterOptions of the Reporter instance that constructed the report, if any.
Activity
yoavweiss commentedon Jan 12, 2023
https://github.com/WICG/pending-beacon may be what you're looking for.
scottpledger commentedon Jan 12, 2023
It's similar, but not quite the same. By building on the infrastructure that clients need to set up in order to enable handling of other types of reports via the Reporting API, clients can handle these as they would any other type of report (eg, using url endpoints or a ReportingObserver).
yoavweiss commentedon Mar 13, 2023
Is there anything preventing you from building a payload that looks like a Report, and sending it to the Reporting API end point using
fetch()?scottpledger commentedon Mar 15, 2023
No, but such a solution has a number of drawbacks compared to the Reporting API, namely:
By building this functionality into the proposed Reporting API, sites can have much cleaner and more consistent reporting functionality with less overhead. This is a massive win for developers and I firmly believe it would significantly improve the adoptability of this API overall.