Type not inferred when accessed as object key

Question

Given the following example:

type Dictionary = {
  [key: string] : string | undefined
}

function greet(name: string) {
  return 'Hello ' + name + '!';
}

function callGreetError(key: string, d: Dictionary) {
  if (typeof d[key] !== 'undefined') {
    return greet(d[key]) // TS Error: Argument of type 'string | undefined' is not assignable to parameter of type 'string'.Type 'undefined' is not assignable to type 'string'.(2345)
  }
  return key + ' is not in dictionary';
}

function callGreetNoError(key: string, d: Dictionary) {
  const storedVal = d[key];
  if (typeof storedVal !== 'undefined') {
    return greet(storedVal) // Error goes away when value is stored in an external var.
  }
  return key + ' is not in dictionary';
}

I'm trying to understand why on callGreetError the type of d[key] inside the if block isn't inferred to be a string even though I'm explicitly telling TS it isn't undefined.

And why storing the value of d[key] on an external var storedVal on callGreetNoError fixes this error.

Yes, same issue.. checking for a value instead of a type doesn't fix it — itaydafna, Feb 03 '20 at 08:20
Does this answer your question? [How to assign string | undefined to string in TypeScript?](https://stackoverflow.com/questions/45194964/how-to-assign-string-undefined-to-string-in-typescript) — Krzysztof Krzeszewski, Feb 03 '20 at 08:20

ford04 · Accepted Answer · 2020-02-03T14:46:43.370

Basically TS won't narrow the property access type of computed property names like key.

const d: Dictionary = {...};
const key = "foo";
const fooProp = d[key];

// using .length as string type check
d["foo"] !== undefined && d["foo"].length; // ✔
fooProp !== undefined && fooProp.length; // ✔
d[key] !== undefined && d[key].length; // error, possibly undefined

It is not, because TS does some mutability check and warns that d[key] value could have changed between the check and its usage. For example following code is perfectly fine for the compiler, but may throw at run-time:

const testDict: Dictionary = {
  get foo() { return Math.random() > 0.5 ? "hey" : undefined }
};

function callGreetError(d: Dictionary) {
  // compiles fine, but throws error at run-time from time to time
  if (d["foo"] !== undefined) d["foo"].length
}
callGreetError(testDict)

To allow proper variable narrowing with control flow, TS must clearly know, what property you mean: by property access with dot notation d.foo or with bracket notation and a literal like d["foo"].

The "trick" with const storedVal = d[key] works, because TS infers the variable type of storedVal to be string | undefined. As control flow analysis in general is based on variables, the compiler now has an easier time narrowing down storedVal with a check for undefined.

Playground

score 1 · Answer 2 · edited Feb 03 '20 at 12:16

1

Just create a temporary variable so you are not accessing the value separately every time. For all typescript knows the value could have changed between the check and its use:

function callGreetError(key: string, d: Dictionary) {
  const temp = d[key];
  if (temp !== undefined) {
    return greet(temp)
  }
  return key + ' is not in dictionary';
}

In this case both checks typeof temp !== "undefined" and temp !== undefined would work

The simplest example showing the problem can be manually assigning a get operator to the dictionary key. In the code sample below you can see that the value of key would be indeed always a string, satisfying type requirements, however it changes with every access

const testDict: Dictionary = {};

Object.defineProperty(testDict, "key", {
  get() { return Math.random().toString() }
});

console.log(testDict.key);
console.log(testDict.key);

Thus checking the type with first access and using it with the second is unrelated

edited Feb 03 '20 at 12:16

itaydafna

1,968
1
13
26

answered Feb 03 '20 at 08:30

Krzysztof Krzeszewski

5,912
2
17
30

Interesting, I think this is the answer I have been looking for - however, this is clearly a synchronous scenario.. Can't TS tell that? – itaydafna Feb 03 '20 at 08:35
2

@itaydafna i edited my answer to include an example typescript is warning you about – Krzysztof Krzeszewski Feb 03 '20 at 08:54
@KrzysztofKrzeszewski it is a reasonable idea, that TS could warn about a potential value change of `d[key]` between its check and usage. But here it is because of the compiler's inability to narrow the property access type in combination with a computed property `key` (made up an answer). – ford04 Feb 03 '20 at 14:28
I'm approving @ford04's answer, as it perfectly answers my questions as well as explains what's flawed in this answer. – itaydafna Feb 03 '20 at 16:08

score 1 · Answer 3 · answered Feb 03 '20 at 08:42

Adding an ! to d[key] in the return statement tells TypeScript that d[key] will not be undefined in this case, although normally it can be. This is known as a non-null assertion operator.

function callGreetError(key: string, d: Dictionary) {
  if (typeof d[key] !== 'undefined') {
    return greet(d[key]!) 
  }
  return key + ' is not in dictionary';
}

A new ! post-fix expression operator may be used to assert that its operand is non-null and non-undefined in contexts where the type checker is unable to conclude that fact. Specifically, the operation x! produces a value of the type of x with null and undefined excluded. Similar to type assertions of the forms x and x as T, the ! non-null assertion operator is simply removed in the emitted JavaScript code.

score -1 · Answer 4 · answered Feb 03 '20 at 08:28

Try doing it like this:

function callGreetError(key: string, d: Dictionary) {
  return d?.[key]
    ? greet(d[key])
    : key + ' is not in dictionary';
}

This way you're making sure that key is not undefined, and not only d[key]. If the syntax confuses you, you can read more about optional chaining here.

Type not inferred when accessed as object key

4 Answers4