[关闭]
@liuhui0803 2017-04-18T01:13:20.000000Z 字数 1752 阅读 1693

Slack从JavaScript切换至TypeScript

开发 TypeScript JavaScript 跨平台 Web开发


摘要:

Slack桌面端工程师Felix Rieseberg撰文介绍了Slack从JavaScript切换至TypeScript充满挑战,但也获得了巨大收益的过程。InfoQ采访了他。

正文:

Slack桌面端工程师Felix Rieseberg撰文介绍了Slack从JavaScript切换至TypeScript充满挑战,但也获得了巨大收益的过程。

为了简化大型JavaScript代码库的管理工作,在放弃使用JSDoc进行函数签名的记录,以及相关用途的描述后,Slack团队决定切换至TypeScript。Rieseberg专门提到,对于现有代码库,很难应用JSON的方法,因为这需要对代码的修改制定严格的约束,但实际上通常可能根本无法轻松地了解预期的类型到底是什么,例如一个Ppromise所要解决的到底是什么问题。

Slack团队选择TypeScript的原因之一在于,TypeScript是JavaScript的超集,因此无须更改现有代码即可使用,并能在采用后逐渐启用其代码分析功能,包括很多流行的软件包中提供类型定义。随着时间的流逝,他们稍后还可以启用高级编译器选项,例如--noImplicitAny,借此防止编译器就any类型进行推断。Rieseberg说他们花了大约六个月的时间为大部分桌面应用的代码添加注解,在这个过程中,编译器发现了很多Bug,并且他们通过诸如自动补全等高级编辑功能大幅加快了开发速度。

InfoQ就这一过程采访了Rieseberg。

您提到才用了循序渐进的方法来启用TypeScript的编译器选项。能否详细说说哪些选项可以在一开始就启用,哪些选项需要在对原有代码进行更多调整之后才能启用?

我认为,any类型是将我们的代码库迁移至TypeScript最强有力的理由之一。该类型可以让我们循序渐进地将any声明稳步替换为更具体的类型和接口。随着使用类型数量的增加,我们迟早会从这种交集与合并的类型所提供的抽象中获益,而这些问题原本是新接触类型系统的开发者最头疼的。在我个人看来,循序渐进地采用TypeScript,这种方法的可行性主要源自它可以接纳现有的JavaScript。TypeScript会试图理解你的代码,并尽可能为你的开发工作提供支持,但就算你没时间将自己的整个代码库一次性移植完成,TypeScript也能让人受益匪浅。

从一种动态的类型切换至一种严格类型的语言,通常可以借机重新设计某些东西。Slack遇到过这种情况吗?

我们向着TypeScript的转换主要是由开发者OJ Kwon负责的,他在加入团队后很快就开始进行了。他发现这一过程中有很多机会可以让我们完善现有代码库。尤其是移植到TypeScript的过程可以帮助我们更好地理解架构内部的数据流动,但从更大范围来说,回顾现有代码始终是一种重新思考所采取的具体方法的好机会。

从语言的层面上来说,TypeScript的哪些功能对于你们构建表达式类型系统最有帮助?

我最喜欢声明合并(Declaration merging),这个功能可以让我们重用现有类型和声明,借此表达我们所要实现的目标。此外虽然关注度略低,但我们的代码库中还大量用到了字符串字面量(String literal)类型。

您刚才强调说,TypeScript最大的优势之一在于它是JavaScript的超集。从另一方面来看,这也意味着无法完全确信你从应用的纯JavaScript层所获得的任何东西。对此您是怎么看的?这是否会造成什么问题?

有必要指出一点,围绕TypeScript还有一个名为Salsa的项目,这是一种开发服务器,可以在使用JavaScript时提供类似于TypeScript的体验。正是该项目的引擎帮助Visual Studio Code理解JavaScript。开发过程中我们配合使用了TypeScript、声明文件,以及Salsa,结果还不错。我个人很喜欢TypeScript对声明文件的处理方法。

作者Sergio De Simone阅读英文原文Moving from JavaScript to TypeScript at Slack

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注