概述

typescript 2.4 为标识符实现了拼写纠正机制。即使咱们稍微拼错了一个变量、属性或函数名，typescript 在很多情况下都可以提示正确的拼写。

typescript 2.7 支持 ecmascript 的数字分隔符提案。 这个特性允许用户在数字之间使用下划线（_）来对数字分组（就像使用逗号和点来对数字分组那样）。

数字分隔符不会改变数字字面量的值，但分组使人们更容易一眼就能读懂数字。

这些分隔符对于二进制和十六进制同样有用。

注意，可能有些反常识，js里的数字表示信用卡和电话号并不适当，这种情况下使用字符串更好。

当咱们将target设置为es2015编译的上述代码时，typescript 将生成以下js代码：

in操作符细化和精确的 instanceof

typescript 2.7带来了两处类型细化方面的改动 - 通过执行“类型保护”确定更详细类型的能力。

首先，instanceof操作符现在利用继承链而非依赖于结构兼容性， 能更准确地反映出 instanceof操作符在运行时的行为。 这可以帮助避免一些复杂的问题，当使用 instanceof去细化结构上相似（但无关）的类型时。

其次，in操作符现在做为类型保护使用，会细化掉没有明确声明的属性名。

更智能的对象字面量推断

在 js 里有一种模式，用户会忽略掉一些属性，稍后在使用的时候那些属性的值为undefined。

在以前typescript会查找{ value: number }和{}的最佳超类型，结果是{}。 这从技术角度上讲是正确的，但并不是很有用。

从2.7版本开始，typescript 会“规范化”每个对象字面量类型记录每个属性， 为每个undefined类型属性插入一个可选属性，并将它们联合起来。

在上例中，foo的最类型是{ value: number } | { value?: undefined }。 结合了 typescript 的细化类型，这让咱们可以编写更具表达性的代码且 typescript 也可理解。 看另外一个例子：

这里，typescript 可以通过检查b属性来细化bar的类型，然后允许我们访问bdata属性。

unique symbol 类型和常量名属性

typescript 2.7 对ecmascript里的symbols有了更深入的了解，你可以更灵活地使用它们。

一个需求很大的用例是使用symbols来声明一个类型良好的属性。 比如，看下面的例子：

可以看到，typescript 可以追踪到x拥有使用符号foo和bar声明的属性，因为foo和bar被声明成常量。 typescript 利用了这一点，让foo和bar具有了一种新类型：unique symbols。

unique symbols是symbols的子类型，仅可通过调用symbol()或symbol.for()或由明确的类型注释生成。 它们仅出现在常量声明和只读的静态属性上，并且为了引用一个存在的unique symbols类型，你必须使用typeof操作符。 每个对unique symbols的引用都意味着一个完全唯一的声明身份。

因为每个unique symbols都有个完全独立的身份，因此两个unique symbols类型之前不能赋值和比较。

另一个可能的用例是使用 symbols做为联合标记。

更严格的类属性检查

typescript 2.7 引入了一个新的编译器选项，用于类中严格的属性初始化检查。如果启用了--strictpropertyinitialization标志，则类型检查器将验证类中声明的每个实例属性

• 是否有包含undefined的类型
• 有一个明确的初始值设定项
• 在构造函数中被明确赋值

--strictpropertyinitialization选项是编译器选项系列的一部分，当设置--strict标志时，该选项会自动启用。 与所有其他严格的编译器选项一样，咱们可以将--strict设置为true，并通过将--strictpropertyinitialization设置为false来有选择地退出严格的属性初始化检查。

请注意，必须设置--strictnullcheck标志(通过—strict直接或间接地设置)，以便--strictpropertyinitialization起作用。

现在，来看看严格的属性初始化检查。如果没有启用--strictpropertyinitialized标志，下面的代码类型检查就可以了，但是会在运行时产生一个typeerror错误：

出现运行时错误的原因是，username属性值为undefined，因为没有对该属性的赋值。因此，对tolowercase()方法的调用失败。

如果启用——strictpropertyinitialize，类型检查器将会报一个错误：

接下来，看看四种不同的方法，可以正确地输入user类来消除类型错误。

解决方案1：允许定义

消除类型错误的一种方法是为username属性提供一个包含undefined的类型：

现在，username属性保存undefined的值是完全有效的。但是，当咱们想要将username属性用作字符串时，首先必须确保它实际包含的是字符串而不是undefined的值，例如使用typeof

解决方案2:显式属性初始化

消除类型错误的另一种方法是向username属性添加显式初始化。通过这种方式，属性将立即保存一个字符串值，并且不会明显的undefined：

解决方案3: 使用构造函数赋值

也许最有用的解决方案是将username参数添加到构造函数中，然后将其分配给username属性。这样，每当构造user类的实例时，调用者必须提供用户名作为参数：

咱们 还可以通过删除对类字段的显式赋值并将public修饰符添加到username构造函数参数来简化user类，如下所示：

请注意，严格的属性初始化要求在构造函数中所有可能的代码路径中明确分配每个属性。 因此，以下代码类型不正确，因为在某些情况下，我们将username属性赋值为未初始化状态：

解决方案4:明确的赋值断言

如果类属性既没有显式初始化，也没有undefined的类型，则类型检查器要求直接在构造函数中初始化该属性;否则，严格的属性初始化检查将失败。如果咱们希望在帮助方法中初始化属性，或者让依赖项注入框架来初始化属性，那么这是有问题的。在这些情况下，咱们必须将一个明确的赋值断言(!)添加到该属性的声明中：

通过向username属性添加一个明确的赋值断言，这会告诉类型检查器，期望对username属性进行初始化，即使它自己无法检测到这一点。现在咱们的责任是确保在构造函数返回后明确地将属性赋值给它，所以必须小心;否则，username属性可能被明显的undefined或者在运行时就会报typeerror错误。

显式赋值断言

尽管咱们尝试将类型系统做的更富表现力，但我们知道有时用户比typescript更加了解类型。

上面提到过，显式赋值断言是一个新语法，使用它来告诉 typescript 一个属性会被明确地赋值。 但是除了在类属性上使用它之外，在typescript 2.7里你还可以在变量声明上使用它！

假设我们没有在x后面加上感叹号，那么typescript会报告x从未被初始化过。 它在延迟初始化或重新初始化的场景下很方便使用。

以上就是详解ts数字分隔符和更严格的类属性检查的详细内容，更多关于ts的资料请关注其它相关文章！