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

Multiple index signatures allowing different index types #44468

Closed
5 tasks done
ghost opened this issue Jun 6, 2021 · 4 comments
Closed
5 tasks done

Multiple index signatures allowing different index types #44468

ghost opened this issue Jun 6, 2021 · 4 comments

Comments

@ghost
Copy link

ghost commented Jun 6, 2021

Suggestion

πŸ” Search Terms

Multiple more than one index type property signature type specific member mapping TypeScript TS

βœ… Viability Checklist

My suggestion meets these guidelines:

  • 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, new syntax sugar for JS, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Put further restrictions on index signatures being mapped to member types, driven by the type of the index signature. Basically add multiple index signatures to an interface that map different type keys to different type members. Hugely increases the power of index signatures. Blocked by #26797.

πŸ“ƒ Motivating Example

This:

export type ColorIdentifier =
    `${string}.${string}`
    | 'background'
    | 'contrastActiveBorder' | 'contrastBorder' | 'focusBorder'
    | 'descriptionForeground' | 'errorForeground' | 'foreground';
export type ThemeScopeKey = `[${string}]`;
export interface IThemeScopedColorCustomizations {
    [colorId: ColorIdentifier]: string;
}
export interface IColorCustomizations {
    [colorIdOrThemeScope: ColorIdentifier | ThemeScopeKey]: IThemeScopedColorCustomizations | string;
}

Could be more accurately specified as:

export type ColorIdentifier =
    `${string}.${string}`
    | 'background'
    | 'contrastActiveBorder' | 'contrastBorder' | 'focusBorder'
    | 'descriptionForeground' | 'errorForeground' | 'foreground';
export type ThemeScopeKey = `[${string}]`;
export interface IThemeScopedColorCustomizations {
    [colorId: ColorIdentifier]: string;
}
export interface IColorCustomizations {
    [colorId: ColorIdentifier]: string;
    [themeScope: ThemeScopeKey]: IThemeScopedColorCustomizations;
}

πŸ’» Use Cases

The vscode repo is full of interface collections that could make immediate use of this..

@MartinJohns
Copy link
Contributor

Sounds like a duplicate of #26797.

@ghost
Copy link
Author

ghost commented Jun 6, 2021

#26797 is a blocking issue however I also don't want TypeScript to restrict object literal types (type = {} or interface {}) to one index signature ([key: <key type>]: <member type>).

@MartinJohns
Copy link
Contributor

I'm not sure what you mean by "is a blocking issue".

I also don't want TypeScript to restrict object literal types (type = {} or interface {}) to one index signature ([key: ]: ).

The linked issue does not impose a restriction like that. It's even mentioned explicitly that multiple signatures should be possible:

since these are just index signatures, they can be added into any object type and in multiples.

@ghost
Copy link
Author

ghost commented Jun 6, 2021

Correct! I've got that PR version installed staged on my VM and multiple index signatures work.
πŸ€¦β€β™‚οΈ I think I was half-asleep when I read that PR lol

@ghost ghost closed this as completed Jun 6, 2021
@ghost ghost changed the title Index signature member typing dependent on index type Multiple index signatures allowing different index types Jun 6, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant