Allow for custom reports to be generated & queued

[scottpledger]

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.

[yoavweiss]

https://github.com/WICG/pending-beacon may be what you're looking for.

[scottpledger]

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]

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]

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()?

No, but such a solution has a number of drawbacks compared to the Reporting API, namely:

1. It can only send while some scripting context is active, be it a ServiceWorker, the originating page, etc.
2. It requires every context to have its own store-and-retry mechanism - something which is already built-in to this Reporting API.

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.