Fix Metric types for better TypeScript support

[tunetheweb]

Fixes #351
Fixes #358

It appears you can't just change a type of an interface in Typescript by repeating it.

This PR uses Omit to completely replace the metric value, but then has to do an assertion for ReportCall of the more specific metric XXXReportCall type to the generic ReportCall type.

[jantimon]

fixes #358

[philipwalton]

I think this is probably fine for now since this is internal code...

...but if we're going to be exporting metric-specific versions of all of these types, it seems like ideally we would be able to make the bindReporter() function understand those types as well. E.g. something similar to what we do here:

web-vitals/src/lib/observe.ts

Lines 40 to 44 in 1d2c191

	export const observe = <K extends keyof PerformanceEntryMap>(
	type: K,
	callback: (entries: PerformanceEntryMap[K]) => void,
	opts?: PerformanceObserverInit
	): PerformanceObserver | undefined => {

[tunetheweb]

I couldn't figure out a way to do this as the metrics are not the same (particularly attribution has an extra attribution attribute). But open to pointers here.

Also, unlike in the observe example (where the specific type had to be passed on to the observer), we're treating all the metrics the same in bindreporter, so seemed easier to just assert this as a ReportCallback type and not treat them as the 12 individual types (6 metrics, and 6 metrics with attribution).

[philipwalton]

Gotcha. I think it may be possible, but I don't think it's worth spending time figuring out so 👍

[brendankenny]

Yeah, it's the mismatch between the specific callbacks for the on* methods (e.g. TTFBReportCallback for onTTFB()), and the fact that bindReporter() currently requires its onReport to be able to handle any of the metrics (which e.g. TTFBReportCallback purposefully doesn't) that you get the type error and the need for the type assertion.

I'm happy to take a stab at parameterizing bindReporter after this PR lands. Because bindReporter truly doesn't care about the handler internally, it should be relatively disruption-free type rearranging (and I believe should streamline some metric type stuff at the same time).

[brendankenny]

PR in #359