期待已久的 Typescript

为什么要用 Typescript

关于 Typescript，可以看看以前写过的这篇《关于Typescript》。文末的故事，便是大多数情况下 Typescript 能帮我们解决的痛点。

过了很久之后，想法还是一样：Typescript 这事情，当你管理大点的应用的时候，就会感受到它的好处了。尤其涉及团队配合的时候！

当然，如果你的项目比较小，或是写个小公（工）举（具）、小 demo 的时候， store 状态管理、typescript 编译这些，除非已经很熟悉、没有额外成本的时候，才勉强适合接入。离了具体场景谈架构，都是耍（xia）流（che）氓（dan）。

为什么要用 Typescript？

变量类型不明确

之前带外包写小程序，除了代码风格不一致之外，还遇到一个会变的变量问题。

let formGroups = this.currentStep.formGroups; // 猜猜我的 formGroups 是数组数组 [[], [], []]，还是对象数组 [{}, {}, {}]？
let flattenFields = _.flatten(formGroups); // 不用猜了，我用个 flatten 抹平，它就一定是对象 [{}, {}, {}] 了！

flattenFields.forEach(item => {
  if (item.fields) { // 猜猜我的 item.fields 是数组还是对象？
    flattenFields.push(..._.values(item.fields)); // 不用猜了，我用个 values 抹平，它就一定是对象了！
  }
});

当我帮忙 debug 个问题的时候，打断点看到：

喵喵喵？？？

# 我和外包童鞋的对话：
我：话说你这些到底是什么类型，从命名和上下文都看不出来。。
我：得去翻更细的代码。。

外包童鞋：values好像可以改一下试试

我：是数组还是对象？

外包童鞋：有的是数组，有的是对象
外包童鞋：一般带复数的是数组

我：（刀.jpg）
我：卧槽
我：你这item.fields，有时候是数组，有时候是对象，这样真的好吗
我：大哥
我：（刀.jpg）* 2

接口协议不符合

前端：帮忙看看这个接口为什么返回失败了？
后台：你这个接口字段少了啊，这个xxx
（哼哧哼哧修改）
前端：帮忙看看这个接口为啥又报错了啊？
后台：你这个字段类型不对...我协议里有写的
前端：喔不好意思我改
（哼哧哼哧修改）
前端：（泪光）帮忙看看这个接口为啥还报错？
后台：...你这字段名拼错了啊！！！！

当然，这个案例里稍微夸张了一点，一般我们都会自己一个个对着协议检查哪里不对，但是很多时候被 bug 光环环绕的时候，你就是发现不了问题。

这个时候，我们就可以用 Typescript 来管理接口啦。

interface IDemoResponse {
  date: string;
  someNumber: number;
  otherThing: any;
}

1. 使用约定的变量的时候，会有相关提示（请忽略我的强行any）。

2. 使用约定以外的属性时候，会报错提示。

除此以外，还有很多很棒的用法呢~

一键调整协议

前端和后台协议约定后，就开始各自开发了。但是，我们总会遇到各种各样的问题，可能导致我们的协议变更。

字段的变更什么的最讨厌了，例如后台要把某个接口下date改成day。一般来说前端是拒绝的，你不能说让我改我就得改，我得看看我写了多少代码，评估下工作量。

什么，全局替换？你知道使用date多普遍吗？万一我替换错了咋办？？

这时候，如果你使用了 Typescript 并定义了协议接口的话，就很好办了~

依然是这段代码：

interface IDemoResponse {
  date: string;
  someNumber: number;
  otherThing: any;
}

const demoResponse: IDemoResponse = {} as any;
const date = demoResponse.date; 

1. 选中需要重命名的属性。

2. 按下F2，重新输入属性名。

3. 按下回车，使用到的地方都会更新。

是不是很酷~~~

跨过 Babel 直接使用 ES6/ES7，跨过 eslint 直接使用 prettier

其实小程序工具本身也支持了不少的 ES6 新语法，不过像async/await这种，则还是需要自己搞个 Babel 来编译。

现在直接上 Typescript，连 Babel 都可以直接跳过啦。

Prettier

这里重点推荐 prettier 神器，也是团队配合的好工具啊：

• 项目代码没有配 eslint？导致每次拉下来的代码一大堆冲突？
• 团队成员使用不同的编辑器？有的没有自动格式化？导致拉下来代码还是一堆冲突？
• 用 standard？有些规范和实际项目不符合，但是偏偏没得改？？

偷偷地往项目里装个 Prettier，然后所有的矛盾都不见啦。不管你的代码格式多独特，最终在 Git commit 的时候，就被同化啦，而且 Prettier 的格式化也不会影响到 Git 记录。

小程序与 Typescript

Typescript 编译下就可以用？

其实小程序它最终运行的还是 Javascript，那不是我们直接自己编译下就好了吗？

少年你太天真了。咱们写 Typescript 最重要的是什么呀？是 Typing 库呀！

网上开源的关于小程序和 Typescript 的工具或者脚手架也一大堆，为啥不用呢？因为小程序的 API 在不断地变化呀~

有了官方的支持，即使小程序的 API 变了，我们也可以及时地更新呀（奸笑）~

开箱即用的尝鲜

既然官方提供支持了，义不容辞地使用呀！

1. 首先，我们更新到最近的工具版本，然后创建项目就能看到了：

2. 创建模版，我们来看看代码长什么样子。

我们可以看到，在 package.json 里面多了俩脚本，其实也就是将 ts 文件原地编译，然后上传代码的时候忽略掉了。

3. 仔细瞧瞧代码。

额，好像混入了一些奇怪的东西进去，感叹号是什么鬼？？？

后面问了下开发GG，是因为这里比较特殊，目前定义的文件暂时没法兼顾，等后面的版本会兼容。

终于用上 Typescript 啦，爽歪歪~

调整下代码结构

小项目的话，其实也不用带什么编译啦。不过如果你还想用 less，也想用 typescript，还不想看到项目下面乱糟糟的文件：

index.js
index.ts
index.json
index.less
index.wxss
index.wxml

我们就简单弄个 gulp，把编译加上吧~

然后我们再把 prettier 愉快地加上。这里就不多讲解啦，大家也可以参考我的 demo 项目:
wxapp-typescript-demo

对了，目前官方的 typing 库也不是非常完善，如果需要写组件、插件、小游戏的你，可能会面临一大堆的 any 冲击波噢~

参考

• 小程序工具更新
  
  

结束语

Typescript 的普及度其实不算高，小程序的确是又一次给到惊喜。反观下我们自己呢？有没有被业务代码冲得找不到方向呢？
很多时候，我们总爱说写业务没啥技术提升，但真的是这样吗？我看过很棒的业务代码，从框架设计到具体的实现，开发者都对自己做了很高的要求。而写技术需求代码的，就一定会写得很好吗？
“我们是业务部门，技术肯定不能比”
“随便找一些能用的就好了，不要浪费时间在这些上面”
“能用就行了，不要在意这些细节”
…
写代码是个思考的过程，要对自己有点追求。当然项目急的时候可以理解，事后一定要把欠下的债务给还了。（较真脸）