What is the reason for Object.keys not returning a keyof type in TypeScript?

Question

What is the reason for Object.keys not returning a keyof type in TypeScript?

Wondering why Object.keys(x) in TypeScript doesn't return the type Array<keyof typeof x>? It seems like a missed opportunity as Object.keys outputs that by default. Should I report this on their GitHub repo, or should I just submit a pull request to correct it?

typescript

Answer 1

Answer №1

The decision to maintain the current return type (string[]) is deliberate. But why?

Let's look at an example type:

interface Point {
    x: number;
    y: number;
}

Suppose you have a function like this:

function fn(k: keyof Point) {
    if (k === "x") {
        console.log("X axis");
    } else if (k === "y") {
        console.log("Y axis");
    } else {
        throw new Error("This is impossible");
    }
}

Here's a question for you:

In a well-typed program, can a legitimate call to fn result in an error?

The expected answer is obviously "No". So, what does this have to do with Object.keys?

Now, consider the following code snippet:

interface NamedPoint extends Point {
    name: string;
}

const origin: NamedPoint = { name: "origin", x: 0, y: 0 };

Note that as per TypeScript's type system, all instances of NamedPoint are valid instances of Point.

Let's add a bit more code:

function doSomething(pt: Point) {
    for (const k of Object.keys(pt)) {
        // A proper call only if Object.keys(pt) returns (keyof Point)[]
        fn(k);
    }
}
// Throws an exception
doSomething(origin);

Our perfectly typed program just threw an exception!

There seems to be an issue here! By using keyof T, we've breached the assumption that keyof T constitutes an exhaustive list. This is because having a reference to an object doesn't guarantee that the type of the reference is not a supertype of the type of the value.

In essence, at least one of the following statements must be false:

keyof T represents an exhaustive list of keys of T
A type with additional properties is always a subtype of its base type
It is permissible to alias a subtype value with a supertype reference
Object.keys should return keyof T

Discarding point 1 renders keyof almost useless since it suggests that keyof Point could be something other than "x" or "y".

Getting rid of point 2 would dismantle TypeScript's type system completely.

Similarly, abolishing point 3 would also demolish TypeScript's type system entirely.

However, discarding point 4 is acceptable and prompts you, the programmer, to contemplate whether the object you're dealing with might be an alias for a subtype of the intended target.

The hypothetical solution to make this scenario legitimate without contradiction lies in Exact Types, which would enable the declaration of a new distinct type exempt from point #2. With this feature, it might be viable for Object.keys to solely represent keyof T for declared exact types of T.

Addendum: What about generics?

Some individuals suggested that Object.keys could appropriately return keyof T if the argument was generic. However, that assertion is inaccurate. Here's why:

class Holder<T> {
    value: T;
    constructor(arg: T) {
        this.value = arg;
    }

    getKeys(): (keyof T)[] {
        // Assumed to be correct
        return Object.keys(this.value);
    }
}
const MyPoint = { name: "origin", x: 0, y: 0 };
const h = new Holder<{ x: number, y: number }>(MyPoint);
// 'name' value assigned to 'x' | 'y' variable
const v: "x" | "y" = (h.getKeys())[0];

Or consider this example, where explicit type arguments are unnecessary:

function getKey<T>(x: T, y: T): keyof T {
    // Believed to be feasible
    return Object.keys(x)[0];
}
const obj1 = { name: "", x: 0, y: 0 };
const obj2 = { x: 0, y: 0 };
// 'name' value inhabits 'x' | 'y' typed variable
const s: "x" | "y" = getKey(obj1, obj2);

Answer 2

The decision to maintain the current return type (string[]) is deliberate. But why?

Let's look at an example type:

interface Point {
    x: number;
    y: number;
}

Suppose you have a function like this:

function fn(k: keyof Point) {
    if (k === "x") {
        console.log("X axis");
    } else if (k === "y") {
        console.log("Y axis");
    } else {
        throw new Error("This is impossible");
    }
}

Here's a question for you:

In a well-typed program, can a legitimate call to fn result in an error?

The expected answer is obviously "No". So, what does this have to do with Object.keys?

Now, consider the following code snippet:

interface NamedPoint extends Point {
    name: string;
}

const origin: NamedPoint = { name: "origin", x: 0, y: 0 };

Note that as per TypeScript's type system, all instances of NamedPoint are valid instances of Point.

Let's add a bit more code:

function doSomething(pt: Point) {
    for (const k of Object.keys(pt)) {
        // A proper call only if Object.keys(pt) returns (keyof Point)[]
        fn(k);
    }
}
// Throws an exception
doSomething(origin);

Our perfectly typed program just threw an exception!

There seems to be an issue here! By using keyof T, we've breached the assumption that keyof T constitutes an exhaustive list. This is because having a reference to an object doesn't guarantee that the type of the reference is not a supertype of the type of the value.

In essence, at least one of the following statements must be false:

keyof T represents an exhaustive list of keys of T
A type with additional properties is always a subtype of its base type
It is permissible to alias a subtype value with a supertype reference
Object.keys should return keyof T

Discarding point 1 renders keyof almost useless since it suggests that keyof Point could be something other than "x" or "y".

Getting rid of point 2 would dismantle TypeScript's type system completely.

Similarly, abolishing point 3 would also demolish TypeScript's type system entirely.

However, discarding point 4 is acceptable and prompts you, the programmer, to contemplate whether the object you're dealing with might be an alias for a subtype of the intended target.

The hypothetical solution to make this scenario legitimate without contradiction lies in Exact Types, which would enable the declaration of a new distinct type exempt from point #2. With this feature, it might be viable for Object.keys to solely represent keyof T for declared exact types of T.

Addendum: What about generics?

Some individuals suggested that Object.keys could appropriately return keyof T if the argument was generic. However, that assertion is inaccurate. Here's why:

class Holder<T> {
    value: T;
    constructor(arg: T) {
        this.value = arg;
    }

    getKeys(): (keyof T)[] {
        // Assumed to be correct
        return Object.keys(this.value);
    }
}
const MyPoint = { name: "origin", x: 0, y: 0 };
const h = new Holder<{ x: number, y: number }>(MyPoint);
// 'name' value assigned to 'x' | 'y' variable
const v: "x" | "y" = (h.getKeys())[0];

Or consider this example, where explicit type arguments are unnecessary:

function getKey<T>(x: T, y: T): keyof T {
    // Believed to be feasible
    return Object.keys(x)[0];
}
const obj1 = { name: "", x: 0, y: 0 };
const obj2 = { x: 0, y: 0 };
// 'name' value inhabits 'x' | 'y' typed variable
const s: "x" | "y" = getKey(obj1, obj2);

Answer 3

Answer №2

If you are certain that the object you are working with does not have any additional properties, you can use the following workaround:

const obj = {x: 3, y: 4}
const objKeys = Object.keys(obj) as Array<keyof typeof obj>
// objKeys now holds type ("x" | "y")[]

To make things more efficient, you can move this code snippet to a function:

const getKeys = <T>(obj: T) => Object.keys(obj) as Array<keyof T>

const newObj = {x: 3, y: 4}
const newKeys = getKeys(newObj)
// newKeys now holds type ("x" | "y")[]

For your convenience, here is an example of using Object.entries, referenced from a GitHub issue discussing why this is not the default behavior:

type Pairs<T> = {
  [K in keyof T]: [K, T[K]]
}[keyof T][]

function entries<T>(obj: T): Pairs<T> {
  return Object.entries(obj) as any;
}

Answer 4

If you are certain that the object you are working with does not have any additional properties, you can use the following workaround:

const obj = {x: 3, y: 4}
const objKeys = Object.keys(obj) as Array<keyof typeof obj>
// objKeys now holds type ("x" | "y")[]

To make things more efficient, you can move this code snippet to a function:

const getKeys = <T>(obj: T) => Object.keys(obj) as Array<keyof T>

const newObj = {x: 3, y: 4}
const newKeys = getKeys(newObj)
// newKeys now holds type ("x" | "y")[]

For your convenience, here is an example of using Object.entries, referenced from a GitHub issue discussing why this is not the default behavior:

type Pairs<T> = {
  [K in keyof T]: [K, T[K]]
}[keyof T][]

function entries<T>(obj: T): Pairs<T> {
  return Object.entries(obj) as any;
}

Answer 5

Answer №3

This is currently the top search result on Google for this particular issue, so I thought it would be valuable to provide some guidance on how to move forward.

These strategies have been compiled from extensive discussions found on various issue pages, which are linked in other responses and comment sections.

Let's say you were dealing with code similar to this:

const obj = {};
Object.keys(obj).forEach((key) => {
  obj[key]; // code that needs revising
});

Here are a few approaches to consider:

If you only require values and not keys, utilize .entries() or .values() instead of iterating over the keys.

const obj = {};
Object.values(obj).forEach(value => value);
Object.entries(obj).forEach([key, value] => value);

Create a helper function:

function keysOf<T extends Object>(obj: T): Array<keyof T> {
  return Array.from(Object.keys(obj)) as any;
}

const obj = { a: 1; b: 2 };
keysOf(obj).forEach((key) => obj[key]); // key type: "a" | "b"

Re-cast your type (useful for minimizing code rewrites)

const obj = {};
Object.keys(obj).forEach((_key) => {
  const key = _key as keyof typeof obj;
  obj[key];
});

The most suitable approach for your project will depend on your specific requirements and preferences.

Answer 6

This is currently the top search result on Google for this particular issue, so I thought it would be valuable to provide some guidance on how to move forward.

These strategies have been compiled from extensive discussions found on various issue pages, which are linked in other responses and comment sections.

Let's say you were dealing with code similar to this:

const obj = {};
Object.keys(obj).forEach((key) => {
  obj[key]; // code that needs revising
});

Here are a few approaches to consider:

If you only require values and not keys, utilize .entries() or .values() instead of iterating over the keys.

const obj = {};
Object.values(obj).forEach(value => value);
Object.entries(obj).forEach([key, value] => value);

Create a helper function:

function keysOf<T extends Object>(obj: T): Array<keyof T> {
  return Array.from(Object.keys(obj)) as any;
}

const obj = { a: 1; b: 2 };
keysOf(obj).forEach((key) => obj[key]); // key type: "a" | "b"

Re-cast your type (useful for minimizing code rewrites)

const obj = {};
Object.keys(obj).forEach((_key) => {
  const key = _key as keyof typeof obj;
  obj[key];
});

The most suitable approach for your project will depend on your specific requirements and preferences.

Answer 7

Answer №4

One potential answer

function checkName<W extends string, T extends Record<W, any>>(obj: T) {
  return (name: string): name is keyof T & W =>
    obj.hasOwnProperty(name);
}

const objectKeys = Object.keys(x).filter(checkName(x));

Answer 8

One potential answer

function checkName<W extends string, T extends Record<W, any>>(obj: T) {
  return (name: string): name is keyof T & W =>
    obj.hasOwnProperty(name);
}

const objectKeys = Object.keys(x).filter(checkName(x));

Answer 9

Answer №5

I also encountered a similar problem and came up with a solution by writing some typed functions.

Realizing that Object.keys and Object.entries always return keys as strings, I decided to define a new type called ToStringKey:

/**
 * Retrieves the names of the _typed_ enumerable string properties and methods from an object.
 *
 * Note: Using Object.keys with a specific type could result in inconsistencies between type-checking and runtime behavior.
 * This function is ideal when you are certain about the object's keys.
 */
export const getTypedKeys = Object.keys as <T extends object>(
  obj: T
  // Employing `ToStringKey` because Object.keys returns all keys as strings.
) => Array<ToStringKey<T>>;

/**
 * Obtains an array of _typed_ values from the enumerable properties of an object.
 */
export const getTypedValues = Object.values as <T extends object>(obj: T) => Array<T[keyof T]>;

/**
 * Fetches an array of _typed_ key/values from the enumerable properties of an object.
 *
 * Note: Confining Object.entries to a particular type may lead to discrepancies between type-checking and runtime behavior.
 * Utilize this function when you are sure about the object's keys.
 */
export const getTypedEntries = Object.entries as <T extends object>(
  obj: T
  // Adopting `ToStringKey` due to Object.entries returning all keys as strings.
) => Array<[ToStringKey<T>, T[keyof T]]>;

/**
 * Converts object keys into their respective string literal types.
 */
type ToStringKey<T> = `${Extract<keyof T, string | number>}`;

I would advise against defining these method types globally. Instead, create separate utility functions for them.

Although TypeScript can deduce and handle types, it cannot ascertain runtime-specific traits such as enumerability.

Answer 10

I also encountered a similar problem and came up with a solution by writing some typed functions.

Realizing that Object.keys and Object.entries always return keys as strings, I decided to define a new type called ToStringKey:

/**
 * Retrieves the names of the _typed_ enumerable string properties and methods from an object.
 *
 * Note: Using Object.keys with a specific type could result in inconsistencies between type-checking and runtime behavior.
 * This function is ideal when you are certain about the object's keys.
 */
export const getTypedKeys = Object.keys as <T extends object>(
  obj: T
  // Employing `ToStringKey` because Object.keys returns all keys as strings.
) => Array<ToStringKey<T>>;

/**
 * Obtains an array of _typed_ values from the enumerable properties of an object.
 */
export const getTypedValues = Object.values as <T extends object>(obj: T) => Array<T[keyof T]>;

/**
 * Fetches an array of _typed_ key/values from the enumerable properties of an object.
 *
 * Note: Confining Object.entries to a particular type may lead to discrepancies between type-checking and runtime behavior.
 * Utilize this function when you are sure about the object's keys.
 */
export const getTypedEntries = Object.entries as <T extends object>(
  obj: T
  // Adopting `ToStringKey` due to Object.entries returning all keys as strings.
) => Array<[ToStringKey<T>, T[keyof T]]>;

/**
 * Converts object keys into their respective string literal types.
 */
type ToStringKey<T> = `${Extract<keyof T, string | number>}`;

I would advise against defining these method types globally. Instead, create separate utility functions for them.

Although TypeScript can deduce and handle types, it cannot ascertain runtime-specific traits such as enumerability.

Answer 11

Answer №6

If you follow these steps, the issue will be resolved.

declare global {
  interface ObjectConstructor {
    keys<T>(o: T): (keyof T)[]
    // @ts-ignore
    entries<U, T>(o: { [key in T]: U } | ArrayLike<U>): [T, U][]
  }
}

The reason I included // @ts-ignore is because otherwise TypeScript would display this warning:

Type 'T' is not assignable to type 'string | number | symbol

If anyone has an alternative solution that eliminates the need for // @ts-ignore while still maintaining the dynamic nature of T, please share it in the comments.

In case this code causes issues, you can use the following workaround:

Object.tsKeys = function getObjectKeys<Obj>(obj: Obj): (keyof Obj)[] {
 return Object.keys(obj!) as (keyof Obj)[]
}
// @ts-ignore
Object.tsEntries = function getObjectEntries<U, T>(obj: { [key in T]: U }): [T, U][] {
 return Object.entries(obj!) as unknown as [T, U][]
}
declare global {
 interface ObjectConstructor {
   // @ts-ignore
   tsEntries<U, T>(o: { [key in T]: U }): [T, U][]
   tsKeys<T>(o: T): (keyof T)[]
 }
}

Answer 12

If you follow these steps, the issue will be resolved.

declare global {
  interface ObjectConstructor {
    keys<T>(o: T): (keyof T)[]
    // @ts-ignore
    entries<U, T>(o: { [key in T]: U } | ArrayLike<U>): [T, U][]
  }
}

The reason I included // @ts-ignore is because otherwise TypeScript would display this warning:

Type 'T' is not assignable to type 'string | number | symbol

If anyone has an alternative solution that eliminates the need for // @ts-ignore while still maintaining the dynamic nature of T, please share it in the comments.

In case this code causes issues, you can use the following workaround:

Object.tsKeys = function getObjectKeys<Obj>(obj: Obj): (keyof Obj)[] {
 return Object.keys(obj!) as (keyof Obj)[]
}
// @ts-ignore
Object.tsEntries = function getObjectEntries<U, T>(obj: { [key in T]: U }): [T, U][] {
 return Object.entries(obj!) as unknown as [T, U][]
}
declare global {
 interface ObjectConstructor {
   // @ts-ignore
   tsEntries<U, T>(o: { [key in T]: U }): [T, U][]
   tsKeys<T>(o: T): (keyof T)[]
 }
}

What is the reason for Object.keys not returning a keyof type in TypeScript?

Answer №1

Addendum: What about generics?

Answer №2

Answer №3

Answer №4

Answer №5

Answer №6

Similar questions

Expanding unfamiliar categories

Visual Studio Code unable to locate source maps for typescript debugging

Leverage Async Await for Setting Response Data in TypeScript

Error: The npm-link library encountered an invalid hook call

The error message "TypeError: Unable to access the 'getFullWidth' property of an undefined value when using TSLint and TypeScript" was

What is causing the TypeScript error in the MUI Autocomplete example?

Creating a definition for the use of sweet alerts within a service and incorporating them through

The name is not found when using attribute, but it is found when using extends

Making an Angular 6 HTTP GET call using HTTP-Basic authentication

Unclear value of button when being passed

Build a unique array of identifiers extracted from an object

Creating a ref with Typescript and styled-components: A comprehensive guide

To ensure the specificity selector for material UI in React, it is essential to include an empty CSS definition

Unable to expand the dropdown button collection due to the btn-group being open

What is the best way to trigger a mat-menu to open with just one click, while also automatically closing any other open menus at

Ensure all promises are resolved inside of for loops before moving on to the next

What is the process for obtaining a flattened tuple type from a tuple comprised of nested tuples?

Incorporating a new function into a TypeScript (JavaScript) class method

Ways to access the values of checkboxes that are initially checked by default

Using Angular BehaviorSubject in different routed components always results in null values when accessing with .getValue or .subscribe