w3c / w3c/reporting

Allow for custom reports to be generated & queued

Open
#259 4 comments 0 reactions 1 assignee View on GitHub

@yoavweiss is already working on this.

Since Mar 13, 2023.

Dominant language
Bikeshed
Stars
84
Forks
39
Avg merge
1d 20h
Merged PRs (30d)
1

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.