# 前言前段时间，我所在的好几个群聊都各自部署了机器人，虽然表现形式有点像“你问我答”，但只要慢慢改造，可玩度还是很高的。经过一番摸索之后，笔者也自己写了一个，但由于当时对`TypeScript`并没有很深的理解，担心写出的代码不够优雅或由于某些原因需要重写时所耗费的精力较大，所以便急匆匆的选定了`JavaScript`作为本次开发的不二之选，但问题也随之而来 > 项目背景大概就是上述内容，下面说说我为什么要从JavaScript迁移至TypeScript、如何完成繁重的迁移工作，以及迁移过程中遇到的问题有哪些，并探讨一些TypeScript的特性 # 有必要使用TypeScript吗在这里就不再赘述`TypeScript`优点几何，而是从两个大概方向进行分析 ## 项目本身 ### 生命周期对于长期维护的项目是非常有必要的。因为通过智能的vscode代码提示、以及良好的类型编程习惯，后期无论是维护还是扩展项目，上手时的开发体验都要优于同类JavaScript项目而对于项目足够小，生命周期也足够短，再考虑上开发成本等问题时，这种类型的项目就不如选用JavaScript进行快速开发 ### 业务复杂度如果模块化、组件化在项目中较为盛行，那我想这个项目本身的业务也是偏向复杂的，由此可推断出该项目维护起来的难度也不会太低。而在面对这种大型项目时，倘若选用TypeScript进行开发，那不管是开发效率还是调试项目的成本问题上，TypeScript总会优于JavaScript 但对于业务简单的项目来说，比如后台管理系统，就算页面的数量再庞大，其实对于项目本身的复杂度也提高不了多少（数据就那么多，产生递增的只会是curd），所以只要额外避免bug数量过多，其实就没有必要选用TypeScript作为开发语言 > 不能理解为小项目就应该使用JavaScript，而大项目就应该使用TypeScript。如果一个小项目的数据流交互复杂，那么用TypeScript也是足够有必要的 ## 协作关系 ### 多人开发开发效率往往也与开发人员的数量挂钩，如果团队在开发时需要频繁地沟通，那必然影响效率，而这只是正确的沟通结果，若是由于某个细节出错，那就又要在后期调试中耗费一番功夫。但如果使用TypeScript作为首选语言，出于类型即文档的本能，这样就可以最大程度的减少沟通成本 ### 独自开发如果是独自负责的项目，那么用不用TypeScript的选择权就把握在了自己手里。但选择时也应该好好比较后再决定（毕竟重构项目仍是较为头疼的问题）。选择时要从大的方面进行比较，比如选择TypeScript是否会增加开发成本、JavaScript是松散类型的语言、使用TypeScript可以获得更智能的代码提示... 有没有必要使用TypeScript，还是要看其实际用途，毕竟不同的场景所需的东西也是不同的 # 类型编程会导致TypeScript的开发成本变重吗对于长期使用`TypeScript`开发项目的程序员可能会对“`类型驱动开发`”这种模式并不感冒，因为在项目初期建立时，我们就要考虑类型如何写、怎么写比较好？换句话说，可能`tab.ts`、`app.ts`尚未生成之前，`interface.ts`在项目中就已经家喻户晓了。而在接下来的开发中，只需要遵循已定义好的结构去书写代码，在调试时便能减少一大堆错误，并且在此期间的开发体验也是极好的但对于刚上手TypeScript的朋友来说，“类型驱动开发“这种模式简直就是折磨，可能你每写三行代码，就至少会有一行用到了提前定义好的类型，而这种频繁去定义类型的操作，只会根据业务的复杂度去递增。但必须要清楚的是，你在类型层面所投入的成本越多，你在项目中收获的类型安全与智能的代码提示也就越多 # 如何将JavaScript项目迁移至TypeScript 项目（[小秋GitHub](https://github.com/FuncJin)）在1.x版本使用JavaScript进行扩展与维护，但迁移至TypeScript后，回想起之前使用JavaScript的开发体验（代码提示、调试成本等）实在不如现在。下面具体说说我是如何完成迁移工作的 ## 配置项首先保证项目中必须存在`tsconfig.json`，并根据自己的需求对该配置文件进行修改。而对于配置项严格模式（`strict`）与存在隐式any时是否报错（`noImplicitAny`）来说，为了保证代码的安全性，前者应当始终开启而对于后者来说，如果是迁移项目时对TypeScript还不是特别熟练，可以选择关闭 > 关闭noImplicitAny后，TypeScript将不检查代码中存在的隐式any，当你一旦发现自己有能力驾驭TypeScript这门语言后，还是很有必要开启此选项的 ## 文件后缀 > 换句话说，这一步就是在TypeScript与“anyscript”中进行抉择有了`tsconfig.json`文件后，便可以将`*.js`文件一个一个修改为`*.ts`，而每修改一个`*.js`文件，就应当全部解决掉该文件所暴露出来的类型不匹配问题，至于如何解决掉此时的类型不匹配问题，我认为大概可以从以下两点着手进行 ### any 能够使用`type alias`或`interface`去解决类型不匹配问题，就绝不使用`any`解决，即使最后决定要用`any`了，也不推荐使用显式注解any（`: any`），而是推荐使用类型断言形式的any（`as any`）由于项目刚迁移至TypeScript时最常出现的问题就是类型不匹配，所以必然会经常使用`any`，但同时也要减少对`any`的依赖，因为当使用`any`时，就相当于告诉TypeScript编译器不要对此进行任何类型检查 ### 推断机制必须要清楚TypeScript的自动推断机制是怎样的，以及出现类型不匹配的原因是什么。还要注意，能够使用隐式注解就使用隐式注解，不要为了显式注解而做着重复劳动的工作 ## 依赖声明如果你的项目中用到了第三方库，那么你必须要安装其声明文件如果某个第三方库没有类型声明文件（`*.d.ts`），那么你就得手动去编写该类型声明，其后可以通过三斜线指令（`/// `）去引入，或者通过`declare`关键字完成类型声明如果第三库拥有自己的声明文件，那么直接安装即可。比如我在此项目中用到了`mysql`，那么可以通过`npm i @types/mysql`进行安装 # 理解TypeScript ## TypeScript是结构化类型语言 TypeScript属于结构化类型语言，而不是名义化类型语言。结构化类型是一种编程设计风格，换句话说，结构化只关心对象有哪些属性，而不管属性使用什么名称 ![types_jghlxyy.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/84cca52397f14f0487a17ec0acbb7d16~tplv-k3u1fbpfcp-watermark.image?) 可以看到在`isMale`函数中，只要传递进来的值符合`PersonSex`接口即可，而传递进来的值的名称无所谓，即只看结构，而不看结构名称。因此这也可以称作鸭子类型（即不以貌取人） ## 类型层级 TypeScript中类型的结构如下图所示 ![types_grade_funcjin.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8329cbe2d44b4753a9cd9e3118d1d6fe~tplv-k3u1fbpfcp-watermark.image?) 下面介绍各类型之间的层级关系 ### 子类型子类型：给定两个类型`A`和`B`，假设`B`是`A`的子类型，那么在需要`A`的地方都可以放心使用`B` 例如`Array`是`Object`的子类型、`Tuple`是`Array`的子类型、所有类型都是`any`的子类型、`never`是所有类型的子类型 ### 超类型超类型：给定两个类型`A`和`B`，假设`B`是`A`的超类型，那么在需要`B`的地方都可以放心使用`A` > 超类型与子类型正好相反例如`Array`是`Tuple`的超类型、`Object`是`Array`的超类型、`any`是所有类型的超类型、`never`不是任何类型的超类型 ### 型变的四种方式 - 不变，只能是T - 协变，可以是 <: T - 逆变，可以是 >: T - 双变，可以是 <: T 或 >: T 协变与逆变则可以理解为： - A <: B 指 “A类型是B类型的子类型，或者为同种类型” - A >: B 指 “A类型是B类型的超类型，或者为同种类型” ### A类型是否可赋值给B类型 TypeScript在判断`A`类型是否可赋值给`B`类型时，对于非枚举类型来说，只要满足以下两者之一即可 1. A <: B 2. A是any ## 类型检查 JavaScript属于动态绑定类型，因此会在运行时检查数据类型，以及自动转换数据类型；而TypeScript则不同，它属于渐进编译式静态类型，可以理解为在编辑器中书写代码时就已经绑定好了类型（若类型错误，则立即出现一条红色波浪线），这也就是平常所说的类型只在类型检查这一步进行，而不是在编译时对类型进行检查类型检查时应该注意，类型检查器是根据使用的类型和具体的用法来给出判断，例如 ![types_check1.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4b09c850af4a4e9da8fb3fe55661e052~tplv-k3u1fbpfcp-watermark.image?) 因为`counts`被自动推导为`number[]`，所以`counts`中的所有元素，TS均认为是`number`类型，所以`filter`函数的形参为`number`类型，而`num * '1'`相当于`number * string`，显然，这在TypeScript中是不合法的 ## 显式注解与自动推导不同的语言有不同的类型系统，因此类型系统一般可分为两种：显式类型及自动推导，而TypeScript两种类型系统全部具备 ![types_xszj.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3dcda6b280eb4a248e40204e6592ecb4~tplv-k3u1fbpfcp-watermark.image?) ![types_zdtd.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2c113fe47e544157bc3238979c80d9f4~tplv-k3u1fbpfcp-watermark.image?) 不过在多数情况下来说，最好让TypeScript自动推导，而非使用显式注解 ## 类型字面量 TypeScript中除去`number`、`string`等其它类型外，还存在一种特殊的类型，即范围最窄的类型，例如`1`、`'1'`、`true`这种类型都是字面量类型（不是值，是类型） ![types_lxzml1.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f407694af91a46dbbda3fcc8bec5fe54~tplv-k3u1fbpfcp-watermark.image?) ![types_lxzml2.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/49b398ad22f949c58c9e42b80a125b4b~tplv-k3u1fbpfcp-watermark.image?) 值得注意的是，使用字面量的形式，一旦被赋值就无法再次修改了，因为字面量类型属于范围最窄的类型 ![types_lxzml3.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7c3a082edbed43bfa48fd15b46ddd8fb~tplv-k3u1fbpfcp-watermark.image?) ## 并集类型的注意点并集的概念为：一个并集类型（|）的值不一定属于并集中的某一个成员，还可以同时属于每个成员。如果并集不相交，那么值只能属于并集类型中的某个成员，不能同时属于每个成员虽然概念与其实际用法相对简单，但要额外注意并集与类型字面量的互相结合，要注意区分是不是字面量类型 ![types_bjlx1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/18965de02ce64d43ad5f296b90754464~tplv-k3u1fbpfcp-watermark.image?) 上图中，`person`对象的类型为`Person`，而`Person`的类型为`ZhangSan`与`LiSi`的并集类型，而`ZhangSan`与`LiSi`均是字面量类型，虽然`person.name`的类型为`张三`，这也就随之符合了类型`ZhangSan`的`name`部分，但`person.age`的类型`5`却不能够分配给类型`ZhangSan`的`age`部分，因为不能将字面量类型`5`分配给字面量类型`3`，所以可做如下修改 ![types_bjlx2.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/350f9ca4f77749f790f0fb8a6d110648~tplv-k3u1fbpfcp-watermark.image?) 或者干脆将`ZhangSan`与`LiSi`修改为`string`和`number`类型 ![types_bjlx3.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/671fdaeedd52483291dac7c9dd29c3a7~tplv-k3u1fbpfcp-watermark.image?) ## any/unknow `any`代表任意类型，即Top Type层级；而`unknown`代表未知类型，也属于Top Type层级。但`unknown`相对于`any`来说是比较安全的，因为在执行操作时，不能假定`unknown`类型的值为某种类型的值 ![types_unknown1.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2f07ed4506cd43a7b7df1e5db3dfdba7~tplv-k3u1fbpfcp-watermark.image?) 这时TypeScript会提示我们`count`为`unknown`类型，因为`unknown`类型不能够进行任何操作，所以`count + 1`便抛出了错误，此时只需向TypeScript证明某个值是某个类型即可，例如 ![types_unknown2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/dc61edc286c342098865f209e7777c9a~tplv-k3u1fbpfcp-watermark.image?) 这种做法借助TypeScript基于流的推导这一特性，由此来向TypeScript证明，在`if`块的范围之内，`count`始终为`number`类型，而`if`块之外，依旧为`unknown`类型，如果觉得这种判断方式较为复杂，则可以使用`is`关键字（类型防护）对其进行简单封装 ![types_unknown3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/15a8b1e191df471fb2f850a207fac641~tplv-k3u1fbpfcp-watermark.image?) 但是要注意，这种方式会产生额外的JavaScript代码，即3-5行（`isNumber`函数）也会被一同编译！ > 如果想表达一个未知值，更合理的方式就是使用unknown ## void/undefined 在JavaScript中，以下两个函数的返回值相同 ```javascript const bar = function(){} ``` ```javascript const bar = function(){ return undefined } ``` 而在TypeScript中，函数返回值为`void`时，表示函数没有返回值，如果函数返回值为`undefiend`，则代表函数存在返回值，只是返回值为`undefiend` ![types_void1.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6bd1445c7137455cbfa0ddace1f02a9f~tplv-k3u1fbpfcp-watermark.image?) ![types_undefined1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/eaec29a057a54c2a8834102505728040~tplv-k3u1fbpfcp-watermark.image?) > TypeScript会认为undefined是实际且有存在意义的类型值，而void则是无意义的类型值 ## this `this`不仅可以用做值，也可以用作类型 ```typescript class Set { add() { // 返回一个this实例 return this } } ``` > 对于链式api来说，这是一个特别便利的特性 ## object类型 `object`只能表示该值是一个JavaScript对象（而且不为null），这个JavaScript对象指的是广义的对象（即万物皆对象），例如`object`、`function`、`array`、`number`等 ## {}类型 `{}`类型，除`null`和`undefined`之外的任何类型都可以赋值给空对象类型，使用起来比较复杂，所以应尽量避免使用空对象类型 ## Object与{}的区别使用`{}`时，可以把`Object`原型内置的方法（例如`toString`和`hasOwnProperty`）定义为任何类型，而`Object`则要求声明的类型必须可赋值给`Object`原型内置的类型。例如 ![types_Object_dkh.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7b49cfebbaf145dab1bc2b9b9191ebc1~tplv-k3u1fbpfcp-watermark.image?) `obj`之所以报错是因为`obj`指定的类型为`Object`，而`Object.toString`方法的返回值必须为`string`类型，但`obj.toString`方法却返回了`number`类型，所以TypeScript才会抛出一条红色波浪线 ## 枚举在日常开发中，由于种种原因，我们可能会用到`constant.ts`，比如 ```typescript // ./phone/constant.ts const apple = 'apple' const xiaomi = 'xiaomi' export { apple, xiaomi } ``` 使用这种形式无非就是为了在代码书写时更加方便且安全，但频繁的定义`constant.ts`文件似乎也较为不妥，而枚举的出现也正是为了解决这一问题枚举（`enum`）是一种无序数据结构，用来把键映射到值上（可以理解为用来列举类型中包含的各个值）枚举可以显式指定值，也可以交由TypeScript自行推导 ```typescript // 显式指定值 enum Phone { Apple = 'apple', Xiaomi = 'xiaomi', Oppo = 'Oppo' } console.log(Phone['Apple']) ``` 当为枚举显式指定值时，访问某个键其实就是访问的该键所提前指定好的值。而如果是TS自行推导值，则会稍有变化 ![types_enum_ystd1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/072307f8242c4a888cb5114bb74353cc~tplv-k3u1fbpfcp-watermark.image?) 可以看到`Price.Apple`被推导为了`0`，并开始以此类推，`Price.Xiaomi`是 `1`， `Price.Oppo`是`2` > 这种现象你可以理解为类似于数组下标的机制那如果有的键显式指定值，有的键不显示指定值呢？ ![types_enum_ystd2.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c3444eca32e349c184cec276bbb55170~tplv-k3u1fbpfcp-watermark.image?) 可以看到手动为`Apple`、`Xiaomi`指定了值，所以值不变。而`Oppo`则是由TypeScript自动推导为了`4700`，因为`Xiaomi`为`4699`。所以最好为枚举中的每个成员显式赋值此外，枚举还支持反向查找。这里可以理解为根据`value`找出`key` ![types_enum_fxcz1.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e2808733375d41aeb4323ce5c1599e6a~tplv-k3u1fbpfcp-watermark.image?) 通过上面的描述，你可能会觉得使用`enum`是极容易出现问题的，为此可以使用更加安全的枚举，即`const enum`，注意，`const enum`是`enum`的子集 `const enum`不允许反向查找，例如 ![types_enum_fxcz2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/70e318e5be524623a591e74a7d219ec9~tplv-k3u1fbpfcp-watermark.image?) 除此之外，`enum`与`const enum`生成后的JavaScript代码也并不相同，使用`const enum`生成的JavaScript代码更像`constant.js` ![types_enum_c1.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b00e57b162064237a94b3d8cfeefe17f~tplv-k3u1fbpfcp-watermark.image?) ![types_constenum1.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f32312c7ae5f40fa9318e5a11704ceea~tplv-k3u1fbpfcp-watermark.image?) 无论是`enum`还是`const enum`，在使用时仍然会遇到安全性问题，为此应当避免使用枚举，同样的意图在TypeScript中有着大量更好的表达 > TypeScript一直在努力修复由枚举所带来的安全性问题，但是否真的需要使用枚举，笔者觉得还是要看自己需求，以及目前所处的TypeScript是哪个版本 ## 重载函数重载函数，其实就是有多个调用签名的函数。简单来说，即调用一个函数的多种形式，之所以可以对函数进行重载，得益于TypeScript的静态类型系统比如将数组的`Filter`函数以重载的形式表达出来 ```typescript type Filter = { (arr: number[], f: (item: number) => boolean) : number[], // （A） (arr: string[], f: (item: string) => boolean) : string[], (arr: boolean[], f: (item: boolean) => boolean) : boolean[], } ``` 类型`Filter`以`A`举例来说，它的第一个形参`arr`需为`number`类型的数组，第二个参数`f`为回调函数，该回调函数的形参`item`为`number`类型，且返回值为`boolean`类型，而整个`Filter`函数的返回值为`number`类型的数组同样的需求仍然可以使用泛型进行表达 ![types_fx_filter1.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fab44abbd3024222ba33171720172297~tplv-k3u1fbpfcp-watermark.image?) 类型`Filter`的第一个形参为`T`类型的数组，第二个形参为回调函数，该回调函数的形参`item`为`T`类型，且该回调函数返回值为`boolean`类型。随后`Filter`函数返回`T`类型的数组下面来看`newArr`与`item`的类型 ![types_fx_filter2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/41a64a81683b41e390f1e38008ccff5f~tplv-k3u1fbpfcp-watermark.image?) ![types_fx_filter3.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/46180ae5be2c408781132646721ced74~tplv-k3u1fbpfcp-watermark.image?) 由于传入`_fliter`函数的数组是`number`类型，所以形参`item`是`number`类型。而`_fliter`函数的返回值也为`number`类型的数组 ## 泛型作用域 > 如果把TypeScript比作一个函数，那么泛型就是它的形参声明泛型的位置不仅限定泛型的作用域，还决定TypeScript什么时候为泛型绑定具体的类型下面的`Filter`写法，在使用`Filter`类型时就必须传入`T`类型 ```typescript type Filter = { (arr: T[]): T[] } ``` 而下面这种写法，只需要在调用函数时传入泛型`T`即可 ```typescript type Filter = { (arr: T[]): T[] } ``` ## 条件类型与infer 条件类型所想表达的意思其实与三目一样，例如 ```typescript type A = T extends unknown ? T[] : never ``` 代表如果`A <: unknown`，则返回`T[]`，否则返回`never`类型而在条件类型中声明泛型时，不使用尖括号语法（``），而是使用`infer`语法，即 `infer T`，例如 ```typescript type A = T extends (infer U) ? U : T ``` 条件类型与infer常常结合使用，例如将对象中的键由`下划线命名法`转换为`驼峰命名法` ![trans_key.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7509888867cb45e98558d02b8565fff5~tplv-k3u1fbpfcp-watermark.image?) ## type alias与interface ### 作用域 `let`与`const`拥有自己的块级作用域，而类型别名（`type alias`）也不例外，在作用域链中，内部的类型别名将覆盖外部同名称的类型别名 ![types_typealias_zyy.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8fc7adeb80ec4782a7701b6a98ea6855~tplv-k3u1fbpfcp-watermark.image?) ### 两者区别类型别名与接口的关系可以看成函数表达式与函数声明之间的关系，除去一些细微差别之外，作用基本相同 #### 类型别名更为通用类型别名可以接受任何类型，而接口则只能接受结构 ```typescript // 无法使用接口重写以下类型 type Count = number type Counts = Count | 2 ``` #### 类型扩展 `interface`可以使用`extends`或`implements`关键字实现接口的扩展 ![types_interface_e1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/af939539c49b43499fb0b880b55d1f21~tplv-k3u1fbpfcp-watermark.image?) 而`type alias`使用`&`或`|`等类型运算符来实现扩展 ![types_ta_and1.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/564458b095e5409e984a56ceee3cffbd~tplv-k3u1fbpfcp-watermark.image?) 但是在扩展接口时，`interface`会检查扩展的接口是否可赋值给被扩展的接口。换句话说，两个同名接口之间不能发生冲突 ![types_interface_e2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5a0f72175513432d8289ec7f3a742fd1~tplv-k3u1fbpfcp-watermark.image?) #### 声明合并同一作用域中的多个同名类型别名将导致编译时错误 ![types_ta_and2.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c6004baad3d940e2af6a2c67efdfe43c~tplv-k3u1fbpfcp-watermark.image?) 同一作用域中的多个同名接口将自动合并 ![types_interface_e3.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/154c3491f2ea451f8645c137eaad9e56~tplv-k3u1fbpfcp-watermark.image?) 除此之外，利用接口的合并特性，还可以安全的扩展原型 ```typescript // 为数组增加一个total方法 interface Array { total(item: T[]): T[] } ``` ## 类型缩窄与类型拓宽 ### let与const关键字推导时的区别 `var`、`let`在推导时会尽量将类型拓宽，下图中可以看到`let`会将`1`推导为`number`类型 ![types_tdlet.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0a530d5aeaf4420dbe6af71ea26c378b~tplv-k3u1fbpfcp-watermark.image?) 而`const`在推导时会尽量将类型缩窄，即把值`1`推导为了类型字面量`1` ![types_tdconst1.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/63af6476fb4749a5afd8183981d11c40~tplv-k3u1fbpfcp-watermark.image?) 但如果`const`关键字所对应的是一个对象，例如 ```typescript const person = { name: '鲨鱼辣椒', age: 5 } ``` ![types_tdconst2.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c396560783d743608f1a3957aaa92724~tplv-k3u1fbpfcp-watermark.image?) 通过编辑器可以观察到，此时对象中的类型并不会进行类型缩窄，而是会与`let`的特性保持一致，即类型拓宽。`person.name`被推导为了`string`类型，`person.age`被推导为了`number`类型，这是因为JavaScript对象总是可变的，所以在TypeScript看来，创建对象之后你可能会更新对象的字段，所以TypeScript对这些字段的值进行了类型拓宽，但如果必须要缩窄类型，应该怎么办呢？此时可以手动将其断言为`const`类型 ![types_tdconst3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2342f8d094a248599f5e770229cb8649~tplv-k3u1fbpfcp-watermark.image?) 通过上述示例可以发现const推断出的是字面量，而var/let推断出的则是字面量的基本类型 ### null/undefined 使用`let`关键字初始化为`null`或`undefiend`的变量将自动拓宽为`any`类型 ![types_let_null1.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a5b7ed25e5394cc0b27865bb5590cf9c~tplv-k3u1fbpfcp-watermark.image?) ![types_let_un1.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d016668f02e146b296a6dbb6957cdc1b~tplv-k3u1fbpfcp-watermark.image?) 而使用`const`关键字则不会拓宽为`any`类型 ![types_const_null1.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6b9f2f837b21444abc60890988f60616~tplv-k3u1fbpfcp-watermark.image?) ![types_const_un1.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d10262721fb1468085b5bcb360237f4d~tplv-k3u1fbpfcp-watermark.image?) ### 适当缩窄当类型拓宽的变量离开声明时所在的作用域后，TypeScript将为其分配一个具体类型 ```typescript function test() { const arr = [] // any[] arr.push(1) // number[] arr.push('a') // string[] return arr // (number|string)[] } const result = test() result.push(true) // 报错，不能将boolean分配给number或string类型 ``` ### const类型这里所说的是`const`类型，而不是定义变量的`const`关键字。在类型声明时使用`const`类型可以禁止类型拓宽 ![types_let1.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0506aff13c1d438e80579ded6191fc96~tplv-k3u1fbpfcp-watermark.image?) `const`类型不仅可以阻止类型拓宽，还可以把对象中的成员递归设为`readonly`（不管数据结构的嵌套层级有多深） ![types_const1.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0e84badac6ed41d3ba9653ed42446fa6~tplv-k3u1fbpfcp-watermark.image?) #### tuple 在定义如下语句时，TypeScript会对`arr`中的成员进行类型拓宽 ![types_tuple1.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d2b10bf638054d62bf5622fd384039e0~tplv-k3u1fbpfcp-watermark.image?) 面对这种情况时，可以使用`as const`来禁止类型拓宽 ```typescript const arr = [1, '2', true] as const ``` 但也可使用如下方法 ![types_tuple2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/291da7150fa14408b903b2a8acda769d~tplv-k3u1fbpfcp-watermark.image?) 此时传入`tuple`函数时，TypeScript会认为传入的是字面量，而不是字面量的基本类型 > 至于为什么会对类型进行拓宽处理，上一小节“let与const关键字推导时的区别”已经讲过 ## 声明空间 ### 类型声明空间与变量声明空间在TypeScript中存在两种类型的声明空间，即类型声明空间与变量声明空间。类型是类型，变量是变量，两者不能够混用 ```typescript type Num = 1 const num = Num // 错误 ``` ```typescript const obj = {} type Obj = obj // 错误 ``` 因为是两个声明空间，所以变量名与类型名完全可以冲突 ```typescript const obj = {} type Obj = {} ``` ### 全局作用域默认情况下，在一个新的TypeScript文件中书写代码时，它处于全局命名空间中 ```typescript // a.ts const foo = 1 ``` 而当处于全局命名空间时，很容易发生命名冲突等问题，因此可以使用`export`解决 ```typescript // a.ts const foo = 1 export { foo } ``` 此时整个`a.ts`就是一个本地作用域。可以理解为`export`会在当前文件中创建一个本地作用域 ### 导入值与类型使用`import`导入时，可以通过`type`关键字区分导入的是值还是类型 ```typescript // a为值（变量声明空间） import { a } from './index.ts' ``` ```typescript // b为类型（类型声明空间） import type { b } from './index.ts' ``` ## 何时为对象增加值通常会有这么一种需求，就是先创建一个空对象，但并不立即对它进行赋值，而是在程序运行的某个时刻再为其赋值，下面来演示这种情况 ![types_wdxzjz.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/56a8c411d2d04ac8a602d0236b02d4e1~tplv-k3u1fbpfcp-watermark.image?) 之所以`person.name`与`person.age`会抛出错误，是因为`person`被推导为了空对象，而往空对象中增添新键，这在TypeScript看来是不合法的，那应该如何解决呢？ ### 最好的解决方案最好的解决方案无疑是在初始化时，立即为对象进行赋值，但这往往不够灵活 ```typescript const person = { name: '鲨鱼辣椒', age: 4 } ``` ### 快速解决方案如果项目周期短，想要寻求快速解决方案，那么使用`any`也未尝不可，不过这样也就丧失了TypeScript所提供的类型安全以及智能的代码提示 ```typescript const person = {} as any person.name = '鲨鱼辣椒' person.age = 4 ``` ### 折中的解决方案中庸之道就是提前定义好类型，这样既达到了灵活性，又能够保证类型安全 ```typescript interface Person { name?: string, age?: number } const person: Person = {} person.name = '鲨鱼辣椒' person.age = 4 ``` 这种方案也是比较常见的解决方案，比如可以将后端返回的信息规定为一个接口，而在使用时，只需要遵循该接口对返回的数据进行操作即可 ```typescript interface UserInfo { code: number, status: string, data: any } ``` > 或者你可以将某一处所用到的所有类型，都集中在当下的interface.ts中 # 文末文末至此，该[项目](https://github.com/FuncJin)在迁移至TypeScript时所遇到的问题和解决方案大都已呈现在上方，其它特性以及TS类型体操并没有花太多笔墨进行着重描述，大概是因为没有在项目中深度使用的原因。并且笔者对TypeScript本身的理解是类型即文档，而使用TypeScript的很大一部分原因也正是想获得更多的类型安全以及智能的代码提示，以此来大幅提升开发体验。对于类型体操来说，我个人认为实际项目中可能并不会有太多地方需要秀一下TS类型体操，仅此而已 > 由于水平有限，文中错误之处在所难免，敬请读者指正。若喜欢本文章，则可一键三连，感谢！