摘要： TS入门手册。
- 原文：TypeScript，初次见面，请多指教
- 作者：徐祁
Fundebug经授权转载，版权归原作者所有。
为什么用 TS ?
说实话，最开始并没有想把 TS 用到实际项目中来，一来是感觉“类型”会限制 JS 的优势（好吧，就是浪写浪惯了）；二来听闻 TS + Redux 的酸爽滋味，有点望而却步；三来 TS 环境使用的库需要加类型的声明，很多库并不支持，有点担心推进的流畅度 …
这个时候，就需要有一股无形的力量推你一把。推我的是团队正在日益普及 TS, 我希望推动你的可以是这篇文章 ~
接下来，会有 React + TS 的项目为背景，介绍我在初学 TS 开发项目中遇到的一些问题，希望对你有所帮助。
一. 如何优雅的声明类型
1. 基础
不就是比 JS 多了一个类型声明吗？老夫撸起袖子拎起键盘就是一梭子：
interface Basic {
num: number;
str: string | null;
bol?: boolean;
}
轻轻松松，五种 JS 值类型就声明好了。那数组、函数呢？再来：
interface Func {
func(str: string): void;
}
interface Arr {
str: string[];
mixed: Array<string | number>;
fixedStructure: [string, number];
basics: Basic[];
}
除此之外，竟然还可以定义自己的类型呢，比如常用的回调函数，在声明处需要指定回调函数的类型：
event.on('change', function() {});
那这个 on 方法需要如何声明呢？试试看 Function当 cb 函数的类型呢
on(type: string, cb: Function): {}
然后就恭喜了，你会得到一个 tslint error :
庆幸的是，在这个 error 里面它告诉了你应该怎么做：声明一个专用的函数类型就可以了：
type Cb = () => void;
on(type: string, cb: Cb);
至此，我们的 TS 人生算是起步了
另外，枚举类型也是很常用的，比如声明一个状态机的各个状态：
enum Status {
Draft,
Published
}
// 也可指定值
enum Status {
Draft = 'Draft',
Published = 'Published'
}
在使用枚举的时候，常会遇到如何将枚举和原始数据类型相互转换的需求，比如接口请求到的 status 是 Draft 字符串，但是代码中声明的 status 是 Enum 类型，如何转换呢？
// string to enum
const str = 'Draft';
const status: Status = Status[str];
// enum to string
Status[Status.Published] === 'Published'
2. 糅合
独立的类型或接口声明看起来似乎并没有那么难，到项目中糅合一下呢？
- 可能会有几十个类型声明；
- 类型声明可能出现在接口入参出参中、React 组件的 Props 和 State 中、函数方法中；
- 当项目到达一定规模，可以抽象出独立的库的时候，类型也需要抽象；
- …
你可能遇到各种情况，会打破你对 TS 的掌控。如何是好？
先说我们实践下来的结论：独立声明、就近声明、按职责分组、杜绝“硬凑”关联、有限抽象。
- 独立声明
一个 ts 文件只声明一个类型或者接口，文件名为需要暴露的类型名称，方便检索和管理。
- 就近声明
当一个声明没有被外部引用或者依赖时，可以考虑就近放在使用的地方，典型的场景是 React 组件的 Props 和 State 的类型声明。
- 按职责分组
在项目中，需要声明类型的可大致分为两类：一类是 model，也就是接口请求相关的，包括入参和出参；另一类是 view，界面渲染相关的。因此，我在 独立声明 的基础上，可以类型按照model 和 view 的维度进行分组，相互独立。
那么问题来了，如果是独立的类型声明的话，怎么把 model 的数据应用到 view 呢？ 可能你需要一个 adapter 来做类型的的转换：DTOTypes -> adapter -> ViewTypes, 完成类似于将接口中的字符串映射成枚举类型这之类的转换。
- 杜绝“硬凑”关联
不要硬凑两个接口或者类型的关系，比如一个接口的创建和更新，可能字段都是一样，区别是一个有 id 另一个没有，于是我们可能就想着写一个类型然后 id 可选就好了。这样是少写了一个类型，但是可能会带来另外一些麻烦，比如带 id 的数据传给了新建的接口，但是 ts 检查不出来。所以，建议不要怕麻烦，直接拆分成 CreateInputDTO 和 UpdateInputDTO.
- 有限抽象
在杜绝“硬凑”关联的基础上，我们可以抽象出通用的声明。
基于上述原则，解决了我作为一个初学者在类型声明上的困扰，如有不对的或者更好的建议，欢迎指正~
3. 万能药膏 any
不是所有的类型声明都能一马平川的，当遇到确实解决不了的类型报错的时候，as any 能带给你不一样的快感，但是不建议使用啊…
二. 如何引用外部库
接下来聊聊第三方库在 TS 环境下的使用。
在 JS 中，npm 上有丰富的海量的库帮我们完成日常的编码，可能并不是所有的库都能完全被应用到 TS 中，因为有些缺少类型声明。
比如，在 TS 中使用 react , 你会得到这样的一个类型检查错误：
因为 react 的库中并没有类型声明。
现在比较通用的做法是，能力实现和类型实现独立成两个库，也就是你需要再安装类型声明的库: @types/react.
当遇到上述问题的时候，尝试安装一下 @types/[package].
然而，并不是所有的库都有类型声明的实现，也会有很多不支持 TS 的存在，然而又必须得使用这个库的时候该怎么办？
自己写声明！
以 progressbar.js为例，基本使用方法是：
import * as ProgressBar from 'progressbar.js';
new ProgressBar.Circle(this.$progress, {
strokeWidth: 8,
trailColor: '#e5e4e5',
trailWidth: 8,
easing: 'easeInOut'
});
我们需要对库中暴露出的 api 去做声明，对上述例子做个分解：暴露了 Circle 类，Circle 构造函数包含两个参数，一个 HTMLElement，一个 options. OK, come on~
// 首先声明一下模块：
declare module 'progressbar.js' {
// 模块中暴露了 Circle 类
export class Circle {
constructor(container: HTMLElement, options: Options);
}
// 构造函数的 Options 需要单独声明
interface Options {
easing?: string;
strokeWidth?: number;
trailColor?: string;
trailWidth?: number;
}
}
如此我们便完成了一个简单的声明，当然实际使用中的 API 肯定比上述情况复杂，根据使用情况，用了哪些 API 或者参数，就补充那些的声明即可。
三. 如何组织一个 TS 项目
TS 项目的目录组织上，跟 JS 项目一样，补充好 types 的声明就可以了。
需要注意的是，将你希望对外暴露的能力相关的类型声明都暴露出去，不友好的声明会让接入你项目的人非常的痛苦，同时，在 package.json 中需要指定 type 的 path, 比如："types": "dist/types/index.d.ts"
另外，务必加上 tslint, 更规范的去用 TS 实现功能，对于入门而言尤为重要。
TS 带来的改变
接触 TS 一个月的感受上来说，过了磨合期的痛苦，就能慢慢感受到 TS 带来的便利。
比如，有一个类型你记得名字是 ABC，你在 VSCode 中输入 A，然后发现，竟然能找到我的声明，按一下回车，卧槽，自动给你 import 进来了，不用在一个个字的输入 …/…/…/…/，不用算目录层级是否正确了，是不是很爽。
另外，强类型并不是没有好处啊，浪写惯了可能还是会留隐患的，有点约束也好 …
虽然你每天要多敲很多 import * as xx from 'xx', 但是你的代码也更为可靠了不是。
与君共勉，提前感受下一代 ES 标准，TS 用起来吧~
坐标南京阿里巴巴，求前端 P7 一枚，岗位要求和待遇同杭州，技术栈限 React，有Typescript 经验者更佳。有意者联系：henry.lx@alibaba-inc.com