Lyft的TypeScript实践
2017-10-22

来自Lyft的前端工程师Mohsen Azimi介绍了Lyft向TypeScript转型的过程,说明JavaScript类型系统的重要性、为什么Lyft选择TypeScript以及他们的一些实践经验。以下内容翻译自作者的博客,查看原文TypeScript at Lyft

在我刚刚成为JavaScript开发者的时候,当有人说要给JavaScript加入类型系统,我就会问自己:为什么要这么做?

现在,我已经成为一个JavaScript老手,我难以想象没有类型系统支持的JavaScript会是怎样的。大型的JavaScript应用需要类型信息来提升扩展性和可维护性,Lyft的很多JavaScript项目(从Lyft.com网站到我们的内部工具)也不例外。当我还是个JavaScript狂热者的时候,看着Lyft的团队和代码库在膨胀,开始意识到纯粹的JavaScript已经无法支撑起大型的应用了。

但这也并非意味着要扔掉JavaScript。如果能够加入类型系统,一切都会变得不一样。类型系统可以减少bug,开发者也因此能够更加方便地查看代码。下面我将讲述Lyft为什么选择了TypeScript以及是怎么做到的。

Bug!

“Uncaught TypeError: Cannot read property "foo" of undefined”是JavaScript最常见的一个错误。在访问一个未定义(undefined)的引用对象的属性时就会发生这个错误。Lyft的纯JavaScript项目在生产环境经常会出现这个问题。JavaScript的常见错误还包括拼写错误,比如“document.getElementbyId”,这类错误在生产环境会引发大问题。

REST API的类型不匹配问题虽然不常见,但一旦发生就是个大bug。比如,API响应消息里的一个字段从数字类型变成字符串类型,会导致JavaScript出现不可预期的行为。

开发效率

浏览大型的JavaScript代码库不仅耗时而且容易让人感到困惑,找不到函数的定义或搞不清楚函数可以接收哪些参数都是常有的事。以下列这段代码为例:

/**
* Create an input element
* @param {string} type
* @param {string|boolean} value
* @return {HTMLInputElement}
*/
function createInput(type, value) {
   const el = document.createElement('input');
   el.type = type;
   if (type === 'checkbox') {
       el.checked = value;
   } else {
       el.value = value;
   }
   return el;
}

这个函数根据传入的类型返回一个HTMLInputElement对象,如果是复选框类型,就把复选框的“checked”属性值设置为传入的值,否则的话就创建一个输入框,并把输入框的值设置为传入的值。

这里可能会出现bug,假设在创建复选框时传入了错误的值,比如:

const input = createInput('checkbox', 'false')

即使代码注释里写得很清楚,仍然无法阻止bug的产生。把字符串“false”赋值给复选框,但复选框的状态仍然会是“true”,因为字符串“false”会被解析成布尔类型的“true”。

而如果有了类型系统,就可以通过重载帮助开发人员写出正确的代码:

/**
* Create an input element
*/
function createInput(type: 'text', value: string): HTMLInputElement;
function createInput(type: 'checkbox', value: boolean): HTMLInputElement;
function createInput(type, value) {
  // code
}

类型系统让代码变得更强大,通过API级别的语义可以在一开始就把bug扼杀在襁褓里。

类型系统让重构变得更简单,开发人员也因此可以放心地做出代码变更。例如,当一个函数签名发生变化,在调用方代码没有做出相应改动之前是无法通过TypeScript编译的。

强类型的代码之所以更容易进行重构,是因为类型检查器可以确保代码变更可以与项目的其他部分兼容。IDE或代码编辑器为类型系统提供了支持。

带有类型信息的模块更容易维护。使用TypeScript开发的模块在一些编辑器里可以显示出API的提示信息。

TypeScript与FlowType的对决

我们有多种JavaScript类型系统可选择:

  • 带有JSDoc类型注解的Google Closure编译器
  • FlowType
  • TypeScript

虽然我们最终选择了TypeScript,但做出这个决定也并不是那么容易的。我们的团队分成两个阵营,一个倾向于选择FlowType,一个倾向于选择TypeScript。

“FlowType就是JavaScript”

FlowType被认为“就是JavaScript”或者“带有类型注解的JavaScript”。这种看法有失偏颇。FlowType是一门独立的语言,它的语法是JavaScript的超集。它使用了.js作为文件扩展名,所以导致了人们的混淆。实际上,不管是JSX还是FlowType,它们都不是JavaScript。同样,TypeScript和ECMAScript也不是。

调用方类型检查

调用方类型检查是FlowType的一个非常受欢迎的特性。比如:

function power2(a) {
   return a * a;
}
power2('string')

这个函数接收一个数字类型的参数,如果在调用时传入了一个字符串,FlowType会对此作出警告。而TypeScript则会认为“a”是任意类型,所以可以通过编译。

这个特性看起来令人印象深刻,但我们只要对代码稍作改动,这个特性就不管用了。比如:

function foo(a) {
    console.log(a.b)
}
foo({})

这段代码可以通过FlowType的编译。

React

因为React和FlowType都是由Facebook开源的,看似FlowType比TypeScript更适合用在React中。但在Lyft的项目中,我们并没有发现把这两者用在React中有什么不同。

流行程度

虽说FlowType和TypeScript看似旗鼓相当,但出于对生态系统未来发展的考虑,我们需要关注它们的流行程度。选择流行程度较高的那一个可以帮助Lyft吸引到更多的开发人才。

要衡量一个开源项目的流行程度并非易事,不过我还是试着努力找出它们之间的对比数据。

StackOverflow上的问题数量:FlowType——900多个;TypeScript——38,000多个。

GitHub上的问题数量:FlowType——1500多个未解决,2200个已关闭;TypeScript——2400多个未解决,11,200个已关闭。

GitHub上的拉取请求:FlowType——60多个未解决,1,200个已关闭;TypeScript——100多个未解决,5000多个已关闭。

npm每月下载数量:FlowType——290多万次;TypeScript——720多万次。

外部类型定义数量:FlowType——340多个,在GitHub上有43000个“流类型”目录,有些库还提供了.flow类型定义;TypeScript——3700多个,在GitHub上有约25万个package.json里包含了类型定义,Facebook的Redux和ImmutableJS也提供了TypeScript类型定义。

我们在内部进行了一个问卷调查,与上述的数据一样,TypeScript在Lyft内部也很受欢迎。

迁移到TypeScript

我们的项目里有大量的纯JavaScript代码,要一下子把它们全部转成TypeScript并非明智的做法。

于是,我们选择了增量迁移。我们使用Webpack编译我们的前端应用,通过TypeScript-loader可以很轻松地将TypeScript引入到Webpack中。有了TypeScript-loader,我们就可以一边使用TypeScript编写新代码,一边零碎地更新旧代码。

TypeScript编译器可以对JavaScript文件进行类型检查,所以我们就利用了这一特性对已有的JavaScript代码进行类型错误检查。当然,这个只对直接被导入到TypeScript中的JavaScript文件有效。不过,最新版本(2.5)的编译器几乎可以直接用于检查独立的JavaScript文件。

推广TypeScript

网上有很多TypeScript的学习资源。TypeScript的官方网站就提供了大量的学习资料,方便开发者入门。另外,TypeScript的语法是JavaScript的超集,所以对于前端开发人员来说非常直观。

lint工具不仅有助于开发者学习TypeScript,对写出一致、流畅的代码也很有帮助。lint工具在没有类型系统的情况下有助于减少有问题的代码,而在有类型系统的情况下就更是能够起到保护代码的作用,所以我们在所有的项目里使用了TSLint。TSLint比一般的lint工具更强大,它可以捕捉到一些很意思的问题,比如awaiting-noon-promise,而这在纯JavaScript的lint工具里是做不到的。

在进行TypeScript培训和往我们的代码库引入TypeScript的过程中,我们发现我们的很多JavaScript代码无法直接使用类型。虽然我们因此感到沮丧,但这也正好说明了我们的代码写得不好,需要进行重构。

Lyft的TypeScript实践

既然引入了TypeScript,Lyft的很多新项目就是纯TypeScript的了。以下是一些使用了TypeScript的项目示例。

TypeScript React转换器

React为它的组件提供了基于运行时的类型系统——PropTypes。我们在Lyft的非TypeScript项目里重度使用了PropTypes。

但在TypeScript里,已经不需要运行时类型检查了,所有的类型检查都发生在编译阶段。于是,我们花了一些时间开发了React JavaScript-to-TypeScript转换器。它利用TypeScript编译器将React组件里的PropTypes转成TypeScript接口。这个工具加速了我们采用TypeScript的进程,为我们节省了大量的时间。

通用异步组件

我们尝试在服务器端动态渲染加载的组件,这个项目完全使用TypeScript开发,它也很好地展示了如何利用类型系统写出可共享的代码。

我们的CSS框架与TypeScript集成

在Lyft,我们使用了一个叫作Tetris的原子CSS库。原子CSS的核心理念是说,重复类名比重复CSS代码的代价更小。原子CSS框架提供了很多小型的CSS类,可以通过组合它们来给元素添加样式。在使用Tetris时,开发人员需要记住大量CSS类名(比如p-a-m,用于给方框增加填充空间)。

为了提升开发效率,我们编写了一个TypeScript文件,它把所有的Tetris类名都导出来,开发人员可以在他们最喜欢的编辑器里导入这个文件,然后就可以使用类名自动完成功能了。

Swagger到TypeScript代码生成

与后端API集成的代码经常会出现bug,这是最让人头痛的问题。后端的变更会影响到前端代码,又或者有时候前端的代码变更会破坏与后端API的兼容性。

我们的后端API是通过OpenAPI(Swagger 2.0)来描述的,我们因此能够规范前端应用的API使用。我们使用Swagger JSON Schema模型为API客户端自动生成TypeScript接口。