Pourquoi Object.keys ne renvoie-t-il pas un type keyof en TypeScript ?

Question

Le titre dit tout - pourquoi ne pas Object.keys(x) en TypeScript renvoient le type Array<keyof typeof x> ? C'est ce que Object.keys le fait, il semble donc que ce soit un oubli évident de la part des auteurs du fichier de définition TypeScript de ne pas faire en sorte que le type de retour soit simplement keyof T .

Dois-je enregistrer un bogue sur leur repo GitHub, ou simplement envoyer un PR pour le corriger pour eux ?

Answer 1

Le type de retour actuel ( string[] ) est intentionnel. Pourquoi ?

Considérez un type comme celui-ci :

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

Vous écrivez un code comme celui-ci :

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");
    }
}

Posons une question :

Dans un programme bien typé, un appel légal à fn a frappé le cas d'erreur ?

Le site souhaité La réponse est, bien entendu, "non". Mais qu'est-ce que cela a à voir avec Object.keys ?

Maintenant, considérez ceci autre code :

interface NamedPoint extends Point {
    name: string;
}

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

Notez que selon le système de types de TypeScript, tous les fichiers NamedPoint sont valables Point s.

Maintenant, écrivons un peu plus de code :

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

Notre programme bien typé vient de lancer une exception !

Quelque chose a mal tourné ici ! En retournant keyof T de Object.keys nous avons violé l'hypothèse selon laquelle keyof T forme une liste exhaustive, car le fait d'avoir une référence à un objet ne signifie pas que le type de la référence n'est pas un supertype du type de la valeur .

Fondamentalement, (au moins) une des quatre choses suivantes ne peut pas être vraie :

1. keyof T est une liste exhaustive des clés de T
2. Un type avec des propriétés supplémentaires est toujours un sous-type de son type de base.
3. Il est légal d'aliaser une valeur de sous-type par une référence de super-types.
4. Object.keys renvoie à keyof T

Balancer le point 1 fait keyof presque inutile, car elle implique que keyof Point pourrait être une valeur qui n'est pas "x" ou "y" .

L'abandon du point 2 détruit complètement le système de types de TypeScript. Ce n'est pas une option.

L'abandon du point 3 détruit aussi complètement le système de types de TypeScript.

Le fait de rejeter le point 4 est une bonne chose et vous amène, en tant que programmeur, à vous demander si l'objet que vous traitez n'est pas un alias pour un sous-type de l'objet que vous pensez avoir.

La "fonctionnalité manquante" pour rendre cette légales mais non contradictoires est Types exacts ce qui vous permettrait de déclarer une nouvelle genre de type qui n'était pas soumis au point n°2. Si cette fonctionnalité existait, il serait vraisemblablement possible de faire de la Object.keys retourner keyof T seulement pour T qui ont été déclarés comme exact .

---

Addendum : Des génériques, c'est sûr, mais ?

Les commentateurs ont laissé entendre que Object.keys pourrait retourner en toute sécurité keyof T si l'argument était une valeur générique. C'est toujours faux. Considérez :

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

    getKeys(): (keyof T)[] {
        // Proposed: This should be OK
        return Object.keys(this.value);
    }
}
const MyPoint = { name: "origin", x: 0, y: 0 };
const h = new Holder<{ x: number, y: number }>(MyPoint);
// Value 'name' inhabits variable of type 'x' | 'y'
const v: "x" | "y" = (h.getKeys())[0];

ou cet exemple, qui ne nécessite même pas d'arguments de type explicites :

function getKey<T>(x: T, y: T): keyof T {
    // Proposed: This should be OK
    return Object.keys(x)[0];
}
const obj1 = { name: "", x: 0, y: 0 };
const obj2 = { x: 0, y: 0 };
// Value "name" inhabits variable with type "x" | "y"
const s: "x" | "y" = getKey(obj1, obj2);

Answer 2

Je vais essayer d'expliquer pourquoi les clés d'objets ne peuvent pas retourner keyof T tout en étant sûres, à l'aide d'un exemple simple.

// we declare base interface
interface Point {
  x: number;
  y: number;
}

// we declare some util function that expects point and iterates over keys
function getPointVelocity(point: Point): number {
  let velocity = 0;
  Object.keys(point).every(key => {
    // it seems Object.keys(point) will be ['x', 'y'], but it's not guaranteed to be true! (see below)
    // let's assume key is keyof Point
    velocity+= point[key];
  });

  return velocity;
}

// we create supertype of point
interface NamedPoint extends Point {
  name: string;
}

function someProcessing() {
  const namedPoint: NamedPoint = {
    x: 5,
    y: 3,
    name: 'mypoint'
  }

  // ts is not complaining as namedpoint is supertype of point
  // this util function is using object.keys which will return (['x', 'y', 'name']) under the hood
  const velocity = getPointVelocity(namedPoint);
  // !!! velocity will be string '8mypoint' (5+3+'mypoint') while TS thinks it's a number
}

Answer 3

Si vous êtes certain que l'objet sur lequel vous travaillez ne contient pas de propriétés supplémentaires, vous pouvez procéder comme suit :

const obj = {a: 1, b: 2}
const objKeys = Object.keys(obj) as Array<keyof typeof obj>
// objKeys has type ("a" | "b")[]

Vous pouvez extraire cela vers une fonction si vous le souhaitez :

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

const obj = {a: 1, b: 2}
const objKeys = getKeys(obj)
// objKeys has type ("a" | "b")[]

En bonus, voici Object.entries tiré de une question GitHub avec le contexte sur la raison pour laquelle ce n'est pas le défaut :

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

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