typescript的基本结构_TypeScript 次日指南

本文首发于我的博客：

TypeScript 次日指南 | 博客​tonghuashuo.github.io

杂谈

不知道是就我这样，还是大家也是，最近的内容圈子里关于 TypeScript 的文章满天飞，各种 TypeScript 有多好、多受欢迎，要不就是 TypeScript 的教程、实践。偏偏我在这时候有了写这篇文章的想法，搞得很有跟风蹭热度的嫌疑。

作为一名坚持原创的作者，我并不想把市面上随手可得的东西，换一种方式再讲给大家听，这样不仅是在浪费大家的时间，也是在浪费我自己的时间。我所理解的为社区做贡献，应该是能够填补当前环境下的一些空白，去做一些真正有意义的事，而不是摆出一副资深的样子，去转发或是创造一些重复的内容。

今天这篇文章，虽然有跟风的嫌疑，但我向你保证，内容依然是绝对的原创。如有巧合，那么英雄所见略同。

为什么是次日？

上手 TypeScript 并不难，有 JavaScript 基础的同学，花个一天时间过一遍文档，基本就都清楚了。如果你刚好还有 Java、C# 等后端语言的基础，那么其中关于 OOP 的一些概念相信你一定会觉得非常眼熟。

如果你刚看完文档就开始准备把 TypeScript 用到项目中去，那么恭喜你，你很快就会遇到各种坑，而且你无法直接从文档中寻找到对应的解决方案。这篇文章的存在，就是希望能够填补这中间的空白，帮助各位顺利的把 TypeScript 落地到项目中。

这便是标题中「次日」的由来。如果你还没有看过 TypeScript 的文档，那么这篇文章现在还不适合你，建议先收藏起来，等看完了文档再回来。

如果你已经准备好了，那我们开始吧。

你或许并不需要 TypeScript

每个人接触 TypeScript 的原因不同，有的是被人安利，有的是因为团队在用，有的是因为用了 Angular。但不管因为什么入了这个坑，我们都需要明白：TypeScript 并非必须。

TypeScript 适合大型项目，小型项目最好还是继续用 JavaScript。这已经是业内的一个共识。

TypeScript 可以简单理解为 JavaScript + Types。从工程效率的角度上讲，Types 的部分属于额外的工作量，如果不能给项目带来足够的收益，去平衡掉其引入的成本，那么这项投入就不是很值得。

如果只是官网之类的小型项目，类型不类型的并不重要，没必要为了用 TypeScript 而用 TypeScript。但随着项目的规模和复杂度的增加，代码质量、沟通成本等问题开始浮现，而这恰恰是类型系统能够解决的问题。通过类型检测，我们可以更早的发现潜在的类型错误，进行主动防御，进而提高代码质量；通过类型定义，我们可以更加直观的描述我们的数据结构，降低团队作业中的沟通成本。

因此，要不要用 TypeScript，取决于你项目的类型以及规模，不要盲目跟风。

别忘了 jsDoc

很多人对 TypeScript 有一个误解，觉得有了静态类型的代码已经足够「自解释」，就不需要 jsDoc 一类的注释了。

静态类型描述的是数据的结构，而注释描述的是数据的作用，两者解决的是不同的问题，彼此之间并不冲突。

比如下面这段 JavaScript 代码：

function convert (val, config) {
    
  //