摘要:现在可以在 Typescript 5.5 Beta 中使用推断的类型断言。在本文中,我将解释这个备受期待的特性以及它如何帮助你编写更加类型安全的代码。
在大多数情况下,Typescript 的控制流分析在监控变量类型随着代码中的移动变化方面相当出色。
例如,考虑以下一个接收string或number的简单函数:
function echo (val: string | number) {if (typeof val === 'string') {console.log(`STRING: ${val}`)return}
console.log(val)}
在这个基本示例中,Typescript 能够轻松判断第 3 行的变量类型是string,第 7 行的变量类型是number。
正确的字符串类型推断
正确的数字类型推断
这很重要,因为 Typescript 可以基于这个推断类型发现错误。例如,如果我们在第 7 行使用错误的字符串方法,我们会收到警告。
这太好了。
现在让我们来看看 Typescript 历史上一直无法解决的一个案例。
什么情况??
考虑这段完美编写的代码:
const values = ["Hello", "World", null, undefined, "Hooray"]
const filteredValues = values.filter((v) => typeof v === 'string')
从开发人员的角度来看,这段代码读起来很顺畅。
我们有一个包含字符串、null和undefined的值列表
我们过滤掉了null和undefined,这样我们就可以处理剩下的字符串值
然而,Typescript 却困惑了。
Typescript 错误:'v' 可能是 'null' 或 'undefined'
即使我们明确过滤了null和undefined,filteredValues的推断类型仍然是(string | null | undefined)[]。
如果你曾经与这个行为作斗争,你并不孤单。
虽然有解决方法来处理这个问题,但从 Typescript 的控制流分析角度来看,这段代码应该开箱即用。
推断的类型断言
当我提到解决方法时,一种解决方式是编写类型断言。
类型断言仅仅是返回布尔值的函数,用于缩小类型范围。
好吧,回到我们讨论的主题。为什么我们一开始就需要解决方法呢?
好消息是,从 Typescript 5.5 Beta 开始,Typescript 将开箱即用地推断类型断言!
实际上,这意味着我们之前编写的代码现在可以开箱即用了。无需解决方法,无需黑客,无需任何修改。
推断的类型断言正在工作
没有错误!
结论
这个看似简单的变更已经酝酿了七年。是的,七年 —— 从最初的问题被提出开始。
Typescript 5.5 Beta 版本带来了许多变化,但没有哪个比推断的类型断言更让我兴奋。有时候,正是这些简单的事情才真正产生影响。至少对我来说是这样。
领取专属 10元无门槛券
私享最新 技术干货