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

TS 5.4.5: Return type for performance.getEntriesByType is inaccurate #58644

Open
lll000111 opened this issue May 24, 2024 · 3 comments · May be fixed by #59166
Open

TS 5.4.5: Return type for performance.getEntriesByType is inaccurate #58644

lll000111 opened this issue May 24, 2024 · 3 comments · May be fixed by #59166
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

@lll000111
Copy link

lll000111 commented May 24, 2024

⚙ Compilation target

ESNexr

⚙ Library

lib.dom.d.ts

Missing / Incorrect Definition

The return type for getEntriesByType is a union of many different object types. A list can be seen in the spec, or at https://developer.mozilla.org/en-US/docs/Web/API/PerformanceEntry ("The PerformanceEntry instances will always be one of the following subclasses:: [List of possibel sub-classes]")

The return type can - and I think should - be hard-coded for the respective string parameter to getEntriesByType, since there is a limited short list of possible string constants, and each corresponds exactly to one possible return type. Maybe an overloaded definition for this function?

Right now the return type is set to PerformanceEntryList, which is PerformanceEntry[], and that type is an interface with only the minimal number of entries.

The effect is that when I use, for example, performance.getEntriesByType('navigation'), I get a TypeScript error trying to access the properties on the PerformanceNavigationTiming array I get from that query.

Sample Code

Playground Link

function pageWasRealoaded(): boolean {
    return performance
        .getEntriesByType('navigation')
        // Error: TS2339: Property type does not exist on type PerformanceEntry
        // This is wrong, because this is a PerformanceNavigationTiming object
        .some(entry => entry.type === 'reload');
}

Documentation Link

https://developer.mozilla.org/en-US/docs/Web/API/PerformanceEntry

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

heysujal commented Jun 21, 2024

@RyanCavanaugh I would like to dive deep into this issue and work on it. I am new to contributing to this project.

@heysujal
Copy link

heysujal commented Jul 1, 2024

interface Performance {

I think I need to make changes here, but what do I need to do?

@lll000111
Copy link
Author

lll000111 commented Jul 1, 2024

I think I need to make changes here, but what do I need to do?

I would use function signature overloads. That's just a bunch of different function header definitions for the same function, describing different combinations of parameters and return type for the same function.

Define one signature-overloaded function for every single type string - see here for the list of string constants and what object type is returned for each - and add the respective return type for that particular input string constant.

That's 14 (if I counted right) lines of one function header definition for each combination of string constant and return object.

I like function signature overloads the most because there is no magic, and they are far more readable than "type magic" stuff. What you see is what you get, it's plainly written, no type calculations and variables/type parameters/generics, or ifs or tertiaries, or indexed access into some helper interface type or whatever.

Apparently you can just write multiple method entries into the interface? Type demo: Playground Link -- I demoed it for one item. You may have to create the interfaces vor the various return objects too, at a glance I did not see e.g. "PerformanceElementTiming" declared yet. I think they all inherit from "PerformanceEntry" (so that inheritance needs to be added to each of the new object interfaces too), which is already defined.

Estimated effort: About half an our of pure typing and opening of MDN pages for each return object type, and checking, little need for thinking. I think.

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.

3 participants