TS的 @types - 类型定义完整指南 - 译文4

这是一篇Angular的课程文章,原文链接在此,我只做翻译。

文章看的懵懵懂懂,不是很了解在说什么,又感觉学到了点啥。

1.结论和建议

如果我们使用的是Typescript,我们有多个类型定义的来源,知道选择哪些类型定义以及为什么选择这些类型定义,对于能够有一个良好的开发者体验至关重要。

我们需要注意一点:编译器总是在增加更多的功能,但现有的库可能还没有利用这些功能。

2.编译器选择类型

我们什么时候应该使用编译器选择类型?

尽量使用编译器内置类型(lib标志)是个好主意,因为这些类型的编写是为了最大限度地保证我们程序的类型安全,确保我们符合标准API。

但根据现有库的现状,它可能会引入其他问题。当选择加入编译器内置类型时,一定要确保它们不会与我们之前已经导入的类型冲突,比如es6-promise,如果不需要的话,使用skipLibCheck也不会影响第三方类型。

但是不要觉得一定要使用选入类型,现在它们被默认关闭是有原因的,这是因为要向后兼容一部分现有的生态系统。

3.使用@types

我们什么时候应该使用@types ?

与其系统地使用@types,不如尽量使用每个模块的内置类型,必要时战略性地使用@types,比如ExpressSequelize这样的模块。

像这两个普通的Javascript模块很可能会成为你程序的主体,并且在@types上有很好的类型可用。但比如像Firebase这样的新模块:它们现在已经带有类型了。

所以如果你也安装了@types/firebase,你会遇到重复的类型问题。

另一方面,像@types/node这样的东西对于编写任何node程序都是必不可少的。

所以这里的建议是:看看内置的类型,看看是否有类似于你正在寻找的东西。看看node模块本身是否已经有类型:这将会越来越常见。

如果既没有在模块内部找到类型,也没有在编译器中内置类型,那么看看@types中是否有一些好的类型。快进到未来,理想的情况是,@typesto不再存在,大多数库都有自己的类型定义。

但这不会很快发生,有这些高质量的类型在那里是很好的。

4.依赖没有类型定义

如果没有类型定义怎么办?

如果一个给定的库没有类型定义文件,也不会妨碍我们使用它。有了Typescript 2.1,我们可以直接导入库,任何导入的库都会被分配为any类型。

所以我们可以与任何现有的Javascript模块无缝集成,而不需要特别的集成。

5.有效利用类型安全

如何确保我们的项目有效利用类型安全?

除了仔细选择我们添加到程序中的类型之外,我们可以做的最好的事情之一就是将noImplicitAny改为true

这样做的效果是,编译器将能够推断出你程序中几乎所有的类型,而代价是只需要一些类型注释,尤其是在函数参数中,这无论如何都是一件很好的事情。

上一篇

TS的 @types - 类型定义完整指南 - 译文3

# TS 

评论

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×