TypeScript 解决了什么痛点？

在我们团队，花了一个双月左右的时间，逐渐把代码全部从 JS 切换到了 TS。对于我们而言，主要的优势有两个：

第一，因为我们使用 monorepo 管理代码，所以在进行代码重构的时候，可以很快发现一些接口或者参数不兼容的情况，提前暴露问题。

第二，我们跟后端服务的接口(HTTP, RPC)是通过 thrift 来约定的，所以开发了一个工具把 thrift 转成 *.d.ts，在调用接口的时候可以很明确的知道应该传递哪些参数，返回值是什么类型。

C/C++, Java 等静态类型语言，是大多数工程师的入门语言。估计静态类型的诸多特性已被习以为常，没有给大家留下深刻的印象。反而会让大家觉得，静态类型很啰嗦，很死板，编译通过太难。

我第一次接触到 Javascript 的时候，也是被 Javascript 的简洁灵活所吸引。所以当我第一次听到 Typescript 的时候，心里想到的，是以前写 C++，Java 的痛苦。

真正了解 Typescript 之后，我才发现 Typescript 和 Java, C++ 等静态类型语言有很大的不同。Typescript 的编程体验可以概括为，既能享受静态类型带来的优点，如 IDE全方位的开发辅助和严格的代码检查；又能让代码像 Javascript 一样简洁和灵活！

Typescript 有很多灵活的设计，不仅仅是静态类型那么简单。

首先 Typescript 全面拥抱了类型推导，随便用 Javascript 写一个 object，ts 都可以推导出完善的 interface 类型。 随着 Typescript 的版本演进，Typescript 的类型推导能力也越来越强大！强大到，Typescript 的类型是可编程的。什么意思呢，用大白话说，我要新定义一个类型，是可以基于已有的类型，通过编程的手段，进行转化加工，最终得到一个新类型。而不是去从头到尾去定义这个新的类型。说到这里要安利笔者的一个库，iron-redux，该 repo 主要做 Redux 的去形式化和 Redux 应用的静态类型完善。该 repo 利用 Typescript 的类型推导能力，能够推导出 redux 整个状态树的类型；Reducer 函数的每个 action case 可以拿到不同的 action payload 类型等等。

与 Java、C++ 不同，Typescript 没有严格要求 100% 的静态类型覆盖。Javascript 代码可以用 Typescript 直接编译通过。所以 Javascript 项目想迁移 Typescript ，只需要批量把后缀改成 .ts，当你在一些地方希望享受静态类型的好处时，再逐渐补充类型定义。而碰到静态类型没有带来实质利益的case，也大可不必定义类型或者用`any` 来定义。目前我们项目的静态类型覆盖率是 88.2%。

举一个 Typescript 的使用案例，我们团队国际化使用的是 kiwi ，一个国际化全流程解决方案，非常好用。kiwi 用 vscode 插件，将代码中的中文抽取到一个 大 Map (ts文件)中，并替换成对应的 Map 路径，如 I18N.a.b.c。一开始 I18N 的类型是 any, 后来我只加了一行代码，将其类型定义为 typeof Map & I18NAPI，所有使用到 I18N 的代码都有了类型，并且在项目中检测出十几处路径拼写错误。

在前端这个特定场景中，其原始类型只来源于业务模型和产品需求规格，其它的类型都可以通过这两类类型推导出来，而不需要重复定义。产品需求规格的类型定义少之又少，业务模型是大头。而业务模型的类型，在全面拥抱静态类型的后端代码中，早已仔细定义过一份了。这里我要忍不住介绍笔者开发的神器 pontx，pont x通过 Swagger 解析后端的接口、实体类的数据，然后按用户自定义转换为类型完美的前端接口层代码和业务模型实体类代码。有了 Pontx，项目可以轻松拥有类型完美的业务模型层。并且我们团队因为使用 Pontx，已经一年多没有写任何接口，请求相关的代码了。

如今前端项目越来越庞大，越来越复杂，静态类型简直是刚需，相信 Typescript 也会越来越普及。