为什么用 TS ?

老实说，一开始我并不想把TS用于实际项目。 来到这里，我觉得“类型”会限制JS的优势。 (好啊，我习惯波浪写字)。 二、听到TS Redux的酸，有点畏怯； 三来TS环境下使用的库需要添加类型声明，很多库不支持，推进的顺畅性有点令人担心.

这个时候，需要看不见的力量来支持你。 推动我的是团队越来越普及TS，我想推动你的是这篇文章~

接下来，以React TS项目为背景，介绍我在初学者TS开发项目中遇到的几个问题。 我希望对你有帮助。

初学者的困惑

一.如何优雅的声明类型

1、基础

不仅仅是比JS增加了类型宣言吗？ 老妇人挽起袖子举起键盘是穿梭。

接口基本{

num: number；

str :字符串| null；

bol？布尔型

}

轻而易举地，声明了五种JS值类型。 数组和函数呢？ 再来：

接口func {

func (str :字符串) : void；

}

接口arr {

str: string[]；

混合：阵列字符串| number；

固定结构： [字符串，编号]；

basics: Basic[]；

}

除此之外，居然还可以定义自己的类型。 例如，常用的回调函数必须在声明的位置指定回调函数的类型：

event.on('change '，function ) }；

这个on方法需要怎么声明？ 让我们将Function设置为cb函数的类型

打开(type : string，cb: Function ) : {}

然后恭喜你。 获得tslint error :

幸运的是，这个error告诉了我该怎么办。 声明专用函数类型就可以了。

类型CB=()=void；

on(type:string，cb: Cb；

至此，我们的TS人生开始了

此外，枚举类型也很常用。 例如，声明一个状态机的每个状态。

枚举状态{

草稿、

Published

}

//也可以指定值

枚举状态{

Draft='Draft '，

Published='Published '

}

使用枚举时，经常会遇到如何转换枚举和原始数据类型的需要。 例如，接口请求的status是Draft字符串，但在代码中声明的status是枚举类型。 怎么转换呢？

//string to enum

const str='Draft '；

常数状态3360 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呢？ 类型转换可能需要适配器。 在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 用起来吧~

内容转载自：https://zhuanlan.zhihu.com/p/57958328