Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add types for window.performance.getEntriesByType #33866

Open
4 of 5 tasks
third774 opened this issue Oct 8, 2019 · 7 comments
Open
4 of 5 tasks

Add types for window.performance.getEntriesByType #33866

third774 opened this issue Oct 8, 2019 · 7 comments
Labels
Bug A bug in TypeScript Domain: lib.d.ts The issue relates to the different libraries shipped with TypeScript Help Wanted You can do this
Milestone

Comments

@third774
Copy link

third774 commented Oct 8, 2019

Search Terms

getEntriesByType
PerformanceMark
PerformanceMeasure
PerformanceResourceTiming

Suggestion

Add types for the getEntriesByType API

I found this old issue (Jul 5, 2018) and saw that experimental API's are not included in lib.dom.d.ts. The following API's don't appear to have experimental warnings on them on the MDN docs. Hopefully this means these are no longer experimental and types can be added now?

https://developer.mozilla.org/en-US/docs/Web/API/PerformanceMark
https://developer.mozilla.org/en-US/docs/Web/API/PerformanceMeasure
https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming

Use Cases

Getting specific strongly typed information for the entries when accessed via this API.

Examples

// resources would be of type PerformanceResourceTiming[]
const resources = window.navigation.getEntriesByType("resource");

// resources would be of type PerformanceMeasure[]
const measures = window.navigation.getEntriesByType("measure");

// marks would be of type PerformanceMark[]
const marks = window.navigation.getEntriesByType("mark");

// paints would still be of type PerformanceEntryList
const paints = window.navigation.getEntriesByType("paint");

Checklist

My suggestion meets these guidelines (not sure about the first one):

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.
@third774
Copy link
Author

third774 commented Oct 8, 2019

Doh! Tried to open a PR for this, but looks like the work is over in https://github.com/Microsoft/TSJS-lib-generator. Should I move this issue to that repo?

@RyanCavanaugh RyanCavanaugh added Bug A bug in TypeScript Domain: lib.d.ts The issue relates to the different libraries shipped with TypeScript Help Wanted You can do this labels Oct 17, 2019
@RyanCavanaugh RyanCavanaugh added this to the Backlog milestone Oct 17, 2019
@TaylorPzreal
Copy link

Waiting the feature.

@DerGernTod
Copy link

any updates on this?

@HolgerJeromin
Copy link
Contributor

HolgerJeromin commented Sep 8, 2022

This is fixed since a few versions. Probably 4.4 or even earlier.
microsoft/TypeScript-DOM-lib-generator#1094 (comment)

@HolgerJeromin
Copy link
Contributor

Ok, missed that detail. Current state models spec:
https://w3c.github.io/performance-timeline/#extensions-to-the-performance-interface

But yes could be more clear by adding overridingTypes:
https://github.com/microsoft/TypeScript-DOM-lib-generator#when-the-type-exists-but-is-wrong

BTW, added type debug information to your playground link.

@schickling
Copy link

Is someone aware of any available NPM package that provides the missing types as a workaround for now?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A bug in TypeScript Domain: lib.d.ts The issue relates to the different libraries shipped with TypeScript Help Wanted You can do this
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants