Indexable type - TypeScript

Question

Below syntax,

interface StringArray {
    [index: number]: string;
}

states that when a StringArray is indexed with a number, it will return a string. For example -

let myArray: StringArray;
myArray = ["Bob", "Fred"];
let myStr: string = myArray[0];

So, myArray is type constrained on values stored as string type, by declaring it with type StringArray. Key(index) is always string type, under the hood(JavaScript), despite mentioning it as number

From the below syntax,

class Animal{
  name: string;
}

class Dog extends Animal{
  breed: string;
}

interface NotOkay {
  [x: number]: Animal;
  [x: string]: Dog;   
}

What does NotOkay syntax state?

From the below syntax,

interface NumberDictionary {
    [index: string]: number;
    length: number;    // ok, length is a number
    name: string;      // error, the type of 'name' is not a subtype of the indexer
}

What does NumberDictionary state?

Why these two syntax are wrong? error TS2413 & error: TS2411

?https://www.typescriptlang.org/docs/handbook/interfaces.html — , Nov 25 '17 at 15:22
@betadeveloper I have an idea that, javascript converts indexed object to a string before indexing it. But, I did not get, when that documentation says, *the type returned from a numeric indexer must be a subtype of the type returned from the string indexer*. Firstly, I did not understand the syntax — overexchange, Nov 25 '17 at 15:34
The compiler can infer the valid operations based on type of index and the type of value. In the case of an _NotOkay_ object _o_ that has the number 1 as key and an Animal as its value it would give access to an Animal instead of a Dog when looking up _o_ with the string "1" . The problem is that the property _breed_ is missing in Animals so _o["1"].breed_ will be an invalid operation. If the _number_ index was a subtype of _Dog_, then the operation would be ok because the subtype inherits _breed_ from _Dog_. — , Nov 25 '17 at 20:52
This kind of type check wouldn't totally prevent a runtime error though. It will happily compiles _o["nil"].breed_ even if the "nil" property is undefined in _o_ and it will result in a TypeError when trying to access its breed. — , Nov 25 '17 at 20:54

ehrencrona · Answer 1 · 2017-11-25T16:34:22.610

(as @betadeveloper points out, the examples are taken from the typescript documentation at https://www.typescriptlang.org/docs/handbook/interfaces.html)

1+3) The point the documentation is making is that this declaration is not consistent.

The declaration would seem to say that this code works:

let no: NotOkay

function byString(key: string): Dog {
   return no[key]
}

function byNumber(key: number): Animal {
   return no[key]
}

But the problem is that a lookup of e.g. no[0] is really the same things as no['0'] (it's how JavaScript works). So byString('0') will actually just result in an Animal, not necessarily a Dog.

So to prevent the code above – that looks correct but is in fact wrong for certain string keys (those that happen to be numbers in string form) – TypeScript does not allow the declaration.

2+3) [index: string]: number; says that you can use any string as an index of a NumberDictionary and you will get a number.

On the other hand, name: string; says that the property name is a string. But a property can also be accessed as an index, so e.g. when doing

let nd: NumberDictionary

let a = nd['name']
let b = nd.name

a and b mean exactly the same thing, but the first declaration seemed to say a was a number, whereas the second declaration seems to say b is a string. That's a contradiction and therefore this declaration is also not allowed.

Indexable type - TypeScript

1 Answers1

Linked