Repository navigation
[Feature] Utility type for T[keyof T] or new keyword valueof #37642
Description
Activity
I wonder why
valueofwasn't introduced at the same time askeyof?To add to the reasons & voices in favor: a
valueofkeyword 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
valueofsyntax would be much cleaner:// Type: 200 | 400 | 500 type StatusCodeValue = valueof typeof StatusCodes;
Reacted by Dmytro Lyfarenko and Piotr Kowalskivalueofas a keyword makes so much sense, I feel like having a keyword in line withObject.valuesis a logical progression fromkeyofbeing in line withObject.keys.In fact, why don't we have some more keywords for some of the most used
ObjectConstructormethods?// 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
ObjectConstructorto 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 { ... }andentrieswas 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 forvaluesandentries, 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.
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
keyofkeyword would suggest avalueofshould 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
Checklist
My suggestion meets these guidelines:
Perhaps some conflict on point 8...