TypeScript 解决了什么痛点？

所谓TS，就是：Talk is cheap, Show me the code.（狗头

一个最简单的state方法，这是在没有TypeScript的情况下:

IDE根本不知道setState的参数类型是个state的迭代回调，回调参数里前后两个count均得不到任何IDE的提示，你看到的截图里的count还是VSCode根据代码中出现的单词(abc)猜的，写React的童鞋应该知道当state稍微复杂一点儿时这会有多令人抓狂。

再来看看在引入Typescript后的表现：

很明显这次代码提示友好多了，IDE知道了你的参数类型是个state的迭代回调函数，知道了这个函数的参数对象里有个名为count类型为number的key，返回值也同理。

回过头看，我们仅仅多付出了两行代码的改动。虽然单纯从代码运行的角度看，这两行代码是额外的，但其实从代码正确和程序可读上看，这两行代码必不可少。特别是在团队开发中，如果你没有这两行代码，那么你也必须通过JSDoc或其它类似的东西来声明清楚接口类型，那么为何不选择一种更优雅简单的方案呢？

上面这个例子太简单，我们看看类似的例子在实际开发场景(React)下的运用。

很明显，如果这时候你还像第一个例子那样，仅仅保证代码能正常运行，那么你会收到一条missing props的警告。你可以选择用ignore干掉这条警告，但在团队合作项目里，我猜你们老大可能更倾向于选择干掉你。。。

在没有Typescript的时候，我们的做法是借助PropTypes来声明props的类型：

但是PropTypes是工作在运行期间的，对于IDE，它能做的只是标示出有没有这个属性，但并不能精确的表明这个属性是什么。这就是为什么React如此重视TypeScript，这个问题在TS里的解决方案是如此之优雅：

可以看到，TS极大优化了IDE提示的友好度，哪怕是个人开发，只要项目稍微复杂一点，你就会发现磨刀不误砍柴工，你为类型正确花费的时间是值得的。

以上两例，我们只讨论了TypeScript作为JS类型补充，对于IDE的语法检测的作用，因为这样配置TypeScript最简单（@babel/preset-typescript），如图中所示，你甚至可以直接在JS里敲TS，可以随时在必要的地方加入几行类型代码而不用改其它地方，TS只会在你加入类型的地方做必要的类型提示，除此之外不会做任何多余的事情，可以说是上手TypeScript最方便的方式了。

可能一些人要杠，FlowType也能做到类似的事情。但实际一个真正的TS项目的威力远不止如此，来看看如果我们把以上index.js重命名为index.tsx会发生什么：

完美，现在TS不止会在你写代码时给出正确的提示，还会在你写下错误的代码时给出提示甚至根据你的配置给出编译时错误了！没有什么比让愚蠢的代码原地爆炸更能保证项目的质量了。

总结：你可以先通过babel配置渐进式的在项目中引入TypeScript，以前的代码一行不用改，只需要在你最需要类型的地方补充一点TS，来获得关键地方的IDE友好的提示（事实上这得感谢babel，在没有babel支持之前FlowType在这点上完虐TS）。当你渐渐熟悉了TS，能熟练的写出各种正确的类型，发现你写的每一个接口都能顺手的自然的带上类型了，你就可以考虑将整个文件重命名为.ts，来获得更友好更强大的IDE支持以及编译时检查。

永远记住，TypeScript就是Type+Script，解决的核心就是JS的Type缺失的问题，这个Type是类型的类不是面向对象的类。用TS根本不需要切换什么代码风格编程范式，TS对面向对象支持的不错，但不代表用TS就一定将以前的JS代码改成Java，强调这个是因为我发现这是我所见到的周围的人拒绝TS的最常见的理由。（事实上JS的进化版：ES就已经把面向对象这块做的很JavaLike了，在这方面TS其实并没有明显优势）