In JavaScript (und daher TypeScript) werden Eigenschaftsschlüssel in string
s erzwungen. Also, wenn Sie eine Immobilie mit einem number
Schlüssel zugreifen, Sie zugreifen tatsächlich eine Eigenschaft mit einem string
Schlüssel:
var obj = {3: 'a', four: 'b'};
console.log(obj['3']); // a
console.log(obj[3]); // a
console.log(obj[3] === obj['3']); // true
Aber es gibt einige string
Schlüssel, die nicht auch number
Schlüssel:
console.log(obj['four']); // b
Der TypeScript-Compiler erzwingt daher, dass der zurückgegebene Wert für den Zugriff auf Schlüssel number
ein Sonderfall des Rückgabewerts für den Zugriff auf Schlüssel string
ist. Zum Beispiel ist die folgende Ordnung:
interface Okay {
[x: string]: Animal;
[x: number]: Dog;
}
Jedes Mal, wenn Sie Zugriff auf ein Okay
mit einem number
Schlüssel, sind Sie eigentlich auch mit einem string
Schlüssel zugreifen. Und da jede number
Schlüsseleigenschaft ist eine Dog
, und jede string
Schlüsseleigenschaft ist eine Animal
, das heißt: jedes Mal, wenn Sie eine Dog
bekommen, erhalten Sie tatsächlich auch eine Animal
. Dies ist nachweislich dem Compiler zuzuordnen; es weiß, dass Dog
eine Unterklasse von Animal
ist und dass jede Dog
eine Animal
ist. So ist TypeScript zufrieden mit Okay
.
Aber folgendes ist nicht in Ordnung:
interface NotOkay {
[x: number]: Animal;
[x: string]: Dog;
}
Jedes Mal, wenn Sie ein NotOkay
mit einem number
Schlüssel zuzugreifen, werden Sie tatsächlich auch mit einem string
Schlüssel zugreifen. Und da jede number
Schlüsseleigenschaft eine Animal
ist und jede string
Schlüsseleigenschaft eine Dog
ist, sagt dieses: jedes Mal, wenn Sie eine Animal
bekommen, erhalten Sie tatsächlich auch eine Dog
. Dies ist nicht nachweislich dem Compiler treu; nicht jeder Animal
ist unbedingt ein Dog
, also TypeScript ist unglücklich mit NotOkay
und beschwert sich.
Hoffnung, das hilft.
Code aus: https: //www.typescriptlang.org/docs/handbook/interfaces. html – Lulu