TypeScript - 防止 null 的类型

Question

我已经为 null object prop 使用了下面的保护类型，但仍然出现错误:

function a(par: {a: string; b: null | string}): {a: string; b: string} | undefined {
  if (par.b === null) {
    return;
  }

  return par;
}

Type '{ a: string; b: string | null; }' is not assignable to type '{ a: string; b: string; }'. Types of property 'b' are incompatible. Type 'string | null' is not assignable to type 'string'. Type 'null' is not assignable to type 'string'.

我认为如果我保护检查 par.b === null，TS 应该推断它不可能返回具有 prop.b === null 的对象。

还是我在这里混淆了什么？

Answer 1

TL;DR:您并不疯狂，但您对编译器的期望超出了它所能提供的。使用类型断言并继续。

---

TypeScript 并不倾向于确定类型保护检查的所有可能含义。检查对象的属性会缩小对象本身的类型的少数几个地方之一是当对象是 discriminated union 时。并且您正在检查的属性是判别属性。在你的情况下，par本身甚至都不是联合类型，更不用说受歧视的联合了。所以当你检查 par.b编译器确实缩小了 par.b但不会将收窄向上传播为收窄 par本身。

它可以这样做，但问题是这样的计算对于编译器来说很容易变得昂贵，如this comment by one of the language architects中所述。 :

It seems that for every reference to x in a control flow graph we would now have to examine every type guard that has x as a base name in a dotted name. In other words, in order to know the type of x we'd have to look at all type guards for properties of x. That has the potential to generate a lot of work.

如果编译器像人一样聪明，它可能只在可能有用时才执行这些额外的检查。或者，也许聪明的人可以编写一些足以满足此用例的启发式方法；但我想在实践中，这在任何人学习该语言的优先列表中都不是很重要。我还没有找到 open issue in GitHub这表明了这一点，所以如果你对此有强烈的感觉，你可能想要提交一个。但我不知道它会受到怎样的欢迎。

在没有更聪明的编译器的情况下，有一些变通办法:

---

最简单的解决方法是承认你比编译器更聪明并使用 type assertion告诉它你确信你所做的是安全的，它不应该太担心验证它。一般来说，类型断言有点危险，因为如果你使用了一个并且你的断言是错误的，那么你只是对编译器撒了谎，由此产生的任何运行时问题都是你的错。但在这种情况下，我们可以非常有信心:

function aAssert(par: {
  a: string;
  b: null | string;
}): { a: string; b: string } | undefined {

  if (par.b === null) {
    return;
  }

  return par as { a: string; b: string }; // I'm smarter than the compiler 🤓
}

这可能是到达这里的方式，因为它使您的代码基本相同并且断言非常温和。

---

另一种可能的解决方法是使用 user-defined type guard缩小的功能par本身。这有点棘手，因为不作用于联合类型的类型保护函数不会在“else”分支中缩小……可能是因为语言缺少 negated types .也就是说，如果你有类型保护 function guard(x: A): x is A & B , 并调用 if (guard(x)) { /*then branch*/ } else { /*else branch*/ } , x将缩小到 A & B在“then”分支内，但只是A在“else”分支中。没有 A & not B要使用的类型。最接近的是做 if (!guard(x)) {} else {} ，但这只是切换缩小了哪个分支。

所以我们可以这样做:

function propNotNull<T, K extends keyof T>(
  t: T,
  k: K
): t is { [P in keyof T]: P extends K ? NonNullable<T[P]> : T[P] } {
  return t[k] != null;
}

propNotNull(obj, key)守卫会，如果它返回 true , 窄 obj到 obj.key 的类型已知不是 null (或 undefined ... 只是因为 NonNullable<T> 是标准实用程序类型)。

现在你的 a()函数可以写成:

function aUserDefinedTypeGuard(par: {
  a: string;
  b: null | string;
}): { a: string; b: string } | undefined {
  if (!propNotNull(par, "b")) {
    return;
  } else {
    return par;
  }
}

支票!propNotNull(par, "b")原因par在第一个分支中根本不会变窄，而是变窄 par至 {a: string; b: string}在第二个分支。这足以让你的代码编译器没有错误。

但我不知道与类型断言相比是否值得额外的复杂性。

---

好的，希望对你有帮助；祝你好运!

Link to code