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

[Feature] Utility type for T[keyof T] or new keyword valueof #37642

Open
5 tasks done
ivoiv opened this issue Mar 27, 2020 · 3 comments
Open
5 tasks done

[Feature] Utility type for T[keyof T] or new keyword valueof #37642

ivoiv opened this issue Mar 27, 2020 · 3 comments
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript

Comments

@ivoiv
Copy link

ivoiv commented Mar 27, 2020

Search Terms

typeof keyof utlity type

Suggestion

Alternative 1:
Create a new Utility type expressing T[keyof T]
Example Value<T> = T[keyof T].

Alternative 2:
Create a new keyword equivalent to T[keyof T]
Example valueof T = T[keyof T]

Use Cases

While T[keyof T] is short and concise, from my experience a lot of developers new to TypeScript usually have no idea what this means or why it's written like that when they first see it.
I also feel that it's not as easy to Google a the answer to that, in comparison to established utility and advanced types like Pick, Omit, Record, etc. which all have their own entries in the TS documentation.

Additionally Object.keys and Object.values are similar concepts.
The presence of a keyof keyword would suggest a valueof should also exist, yet it's missing and one must employ a "special" approach to replicate.

A simple solution is to write my own custom type for the project, but that just introduces additional abstraction and the knowledge/practice isn't transferable to other projects, without implementing the same custom type somewhere in the code first.

And lastly, and this is not a big issue, but I feel it's redundant having to write the type for T twice in on the same line just a few symbols apart.
With short names such as T it's okay, but with longer type names the code becomes more cumbersome to read.

Examples

type T = {
    a: string;
    b: number
    c: number[]
    ...etc
}

// Value<T> = string | number | number[]...
// valueof T = string | number | number[]...

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, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.
    Perhaps some conflict on point 8...
@RyanCavanaugh RyanCavanaugh added Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript labels Mar 27, 2020
@devinrhode2
Copy link

I wonder why valueof wasn't introduced at the same time as keyof?

@JoshuaKGoldberg
Copy link
Contributor

To add to the reasons & voices in favor: a valueof keyword or similar would be quite useful with getting enum-like behavior with const objects.

Today, if you'd like to grab the value out of a const object, you have to use something akin to (typeof MyObject)[keyof typeof MyObject]:

const StatusCodes = {
    InternalServerError: 500,
    NotFound: 404,
    Ok: 200,
    // ...
} as const;

// Type: 200 | 400 | 500
type StatusCodeValue = (typeof StatusCodes)[keyof typeof StatusCodes];

let statusCodeValue: StatusCodeValue;

statusCodeValue = 200; // Ok

statusCodeValue = -1;
// Error: Type '-1' is not assignable to type 'StatusCodeValue'.

A valueof syntax would be much cleaner:

// Type: 200 | 400 | 500
type StatusCodeValue = valueof typeof StatusCodes;

@WillsterJohnson
Copy link

valueof as a keyword makes so much sense, I feel like having a keyword in line with Object.values is a logical progression from keyof being in line with Object.keys.

In fact, why don't we have some more keywords for some of the most used ObjectConstructor methods?

// these exist

Object.keys(obj) -> keyof typeof obj

// this one uses the utility type `Readonly<T>` rather than `readonly T`, close enough
Object.freeze(obj) -> readonly typeof obj

// this feature request

Object.values(obj) -> valueof typeof obj
// provides "v1" | "v2"
type ValueOf<T> = T[keyof T];

// possibly more?

Object.entries(obj) -> entryof typeof obj
// provides ["k1" | "k2", "v1" | "v2"] (not ideal: allows ["k1", "v2"] which is not a valid entry)
type EntryOf<T> = [keyof T, valueof T];
// provides ["k1", "v1"] | ["k2", "v2"] (preferred: associates 1:1 key:value) (hard to read as a util - doesn't matter as a keyword)
type EntryOf<T> = valueof { [K in keyof T]: [K, T[K]] };
// note that these won't be too different in length of generated type for reasonably sized objects

(I should note that I'm not asking for the definitions on ObjectConstructor to be changed to reflect the listed types, I'm simply listing the similar keywords. I believe definition changes have already been discussed elsewhere, plus they're off-topic here so let's leave it at that.)

In all honesty, I went through every method under interface ObjectConstructor { ... } and entries was the only other one that seems reasonable.
(Drifting off-topic slightly) Trying to think of other keywords, I can see that the useful ones I've been able to think of have their respective issues. (if you're interested, I found these: writable, public-ify, nameof)

It's common to cast Object.keys(obj) as keyof typeof obj, or do the same for values and entries, having a way to do so more easily for the latter two would be helpful for everyone who's casting the outputs, and it wouldn't involve changing the type definitions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

5 participants