项目中使用 TypeScript 的一些感悟

上周发布了一款名为 Smartour 的工具，是彻底采用 TypeScript （如下简称 ts）来开发的。抛开之前作业务的时候的不彻底使用，此次实践能够算是我第一次真正意义上的使用 ts。因为写法上的不一样，以及对不熟悉事物的新鲜感，在此次项目开发的过程当中着实有着许多感悟，因而打算写篇小东西好好记录下来。

TS 能让人养成“先思考后动手”的好习惯

在以往的开发过程当中，个人习惯老是“先想好一个大概，而后边作边想再边改”。这样的好处是动做比较快，顺利的时候效率会很高，但更多的时候是不断地推翻本身先前的想法，相信很多的人也有跟我相似的体会。

而使用 ts，能够在必定程度上减小这个问题。众所周知 ts 是强类型的语言，这也意味着它能有效制约开发者在开发过程当中“为所欲为”的程度。就以定义一个函数的参数为例，能够看看我在写 js 和 ts 的思考方式上有什么不一样。

写 js 的时候，个人思考过程是这样的。

1. 首先这个参数是一个对象，这个对象的属性 el 是一个 css 选择器；而对象的属性 keyNodes 是一个数组，里面的元素是一系列的 keyNode。
2. 这个所谓的 keyNode 也是一个对象，它也包含了一个 css 选择器属性 el，以及一个绑定在 dom 元素上的事件参数 event。
3. 我会把这个参数对象以注释的形式写下来，以便记住它的具体定义。

/** { el: '#demo-id', keyNodes: [{ el: '.item-1', event (e) { console.log(e) } }] } */
复制代码

4. 之后任何地方要用到这个参数，我都要手动保证参数的结构要和这个注释保持一致。

而换成 ts 的写法之后，个人思路是这样的：

1. 首先这个参数是一个对象，这个对象的属性 el 是一个 css 选择器；而对象的属性 keyNodes 是一个数组，里面的元素是一系列的 keyNode。
2. 而后我会经过 interface 把它给定义好：

interface HightlightElement {
    el: string,
    keyNodes: Array<KeyNode>
}
复制代码

interface KeyNode {
    el: string,
    event: EventListener
}
复制代码

3. 在须要用到这个参数的时候，只须要在定义形参的时候传入这个 interface 便可。万一参数结构或内容的类型有误，VScode 编辑器都会马上给予提示，省去了手动检查的麻烦。

someFunction (param: HightlightElement) { ... }
复制代码

能够看到，在写 js 的时候更多的是“本身和本身约定，本身判断是否遵照了约定”，而 ts 则是“本身和本身约定之后，由第三方（编辑器）去判断是否遵照了约定”。这样的好处是除了老生常谈的减小错误以外，更多的则是对思惟上的良性约束。这种良性约束可以让咱们在思考的阶段就定义好接下来要作的一系列事情，在操做的过程当中若是发现任何问题也可以在第一时间溯源回最初思考的起点，排查问题的时候会更加高效。

TS 拥有自成文档的特性

在写 js 的时候，咱们依赖注释去判断某个变量或参数的类型、结构和做用。若是没有了注释，只能经过阅读源码和不断调试去搞清楚当中的细节。许多人在接手他人项目的时候都会有这么一个经历：“为何不写注释！这个函数写的啥！这参数又是啥！”没有注释的 js 代码是让人崩溃的，可是写注释不只须要时间，更考验一我的的归纳能力。说了等于没说甚至误导性的注释，也是足够让人崩溃。

在 ts 中，除了注释之外咱们还有另一个选择，就是查看某个变量或参数所对应的 interface 接口定义。在 interface 中咱们能够很直观地看到参数的结构，内部属性的类型，是否为可选等详细信息。再加上VScode 的智能提示及跳转，不论是查看他人的代码仍是维护一个历史项目，都能更加方便和规范——毕竟写接口每每比写注释要顺手，看接口每每比猜代码要稳妥。

说到自成文档的特性，我也联想到了另一个热门技术 GraphQL。借助 GraphQL 社区配套的一系列工具，调用方在调用接口的时候就能直接读到接口的标准定义；而接口的开发者也不须要额外编写文档，在定义接口的时候其实就至关于把文档也写好了。

自成文档的特性对于多人维护的项目来讲是很是有用的，它可以大大下降项目当中沟通和理解的成本。可是这句话也有一个前提，就是开发者要遵照并合理工具当中的约束规范，若是一个接口的任何参数类型都是 any ，那么也就失去了使用 ts 的意义。

TS 可以下降搭建环境的时间成本

为了同时使用 js 新颖的特性以及兼容陈旧的浏览器，咱们每每会借助一系列的工具去搭建一套开发环境。也许咱们已经习惯了 webpack + babel 的开发方式，但是又有谁可以保证本身在不看文档的状况下可以本身去搭一套呢？且不说这些工具各有着复杂的文档，就算好不容易把环境搭好了，还会发现有着更多“最佳实践”。改来改去花了一天时间，才终于算是完成。

做为 js 的超集，咱们能够在 ts 中放心使用 js 的各类高级能力。因为自带命令行工具，咱们再也不须要去研究 babel 或者各类 preset-env 插件，只须要指定须要构建的版本，ts 命令行工具就会自动为咱们生成对应版本的 js。

固然这并非说有了 ts 就可以彻底抛弃构建工具了，在构建复杂应用（如包含各类静态资源，跨格式文件引用）场景的状况下仍是离不开构建工具的，且在将来很长一段时间都会维持这种情况。可是秉承着“多一事不如少一事”的原则，只要可以减小哪怕是一个工具的使用，对开发者来讲都是有好处的，毕竟咱们都期待着某一个可以只管代码无论环境的日子。

尾声

因为不是 ts 的资深玩家，以上的碎碎念都是做为一个初学者我的的新鲜感。在工做的这些日子里，也深入体会到永远没有百分百理想化的东西。ts 当然是好，但也须要辩证地看待它。咱们是否真的须要 ts？它是否真的可以提升咱们的生产力？它是否真的如他人描述般理想？这些问题都须要通过实践才能回答。说到底 ts 只是一个工具，何时用它，怎么用它，仍是取决于具体的场合。一味地尬吹或者否定其余的东西，只能说明思想仍是太狭隘了。