一些感想 ​

为什么存在 ts ​

一开始有些抗拒 ​

老实说虽然早就接触了ts,而且在上家公司也用上了,但还是感觉挺抗拒的,原因是过多的不必要的代码,比如一个页面所有的功能代码(加上axios请求以及公共utils)是300行,那么加上ts后会有400行的代码甚至更多,特别体现在接口方面的定义上,如果后端接口返回数据本身就很怪异而且因为一些 "人为原因" 导致数据总是不符合期望,那么我做这些严格校验就像是在浮萍上盖楼

过后思考 ​

私下自己想了想,或许是因为我负责的项目比较单一,就两三个前端甚至一个前端一个项目这种就行,如果一直这样的话谁愿意用ts啊,都是自己写的代码都非常熟了,谁愿意多写一些限制自己的东西是不?

但很明显,我们这一行并不是一滩死水,你负责的永远不可能只是某个,某块项目,我试想如果我是技术管理者也不希望有这样的情况,一方面是离职成本会很大:只有他熟悉那一块代码,无论是离职还是换个业务线都不大好;二方面是每个人更像是一枚螺丝钉了,只负责自己熟悉的代码不利于团队技术进步

拥抱ts ​

如果用上了ts,让我们来看看有哪些改变

1. 如果你被突然切换到某个业务线并且要你在当天就有产出,再夸张点就是你必须一个小时内修复一个其他项目的线上bug,按照我以前用js的习惯一般会把一整条逻辑走完我才开始写代码(充分理解每个参数是什么意思,函数内部做了什么返回了什么),如果此项目加上了严格的ts,基本上会杜绝你写出低级bug,而且也能辅助你认识关键代码的入参出参快速修复bug
2. 你不可能一直遇上经常出现 "人为原因" 的后端把,如果遇上了请让其更加严格的要求自己

从技术角度解读ts优点 ​

• js在运行代码前并不知道函数调用的结果,甚至不知道函数是否能被调用
• 代码补全,快速修复更加得心应手
• ts类型系统可以正确推断出一些标识符相对应的类型

安装 & 配置 ​

// 安装
npm install -g typescript

// 编译
tsc index.ts
(没有tsc命令也可以用 npx tsc index.ts)

vscode 配置自动编译 ​

1. 进行一些配置

// 生成 tsconfig.json 文件
ts -init

// 在 tsconfig.json 文件内配置
"outDir": "./js",

2. 在目标单文件中, command + shift + b,然后选择你的 tsconfig 文件
3. 随后在你的目标 index.ts 文件中执行 tsc index.ts
4. 就此你的每次操作都会自动打包

tsconfig.json 其他配置 ​

TypeScript 提供的形式更像是一个刻度盘,你越是转动它,TypeScript 就会检查越多的内容

"strict": true 严格模式
noImplicitAny: true 当隐式类型被推断为any时会抛出一个错误
strictNullChecks: true 选项会让我们更明确的处理 null 和 undefined,也会让我们免于忧虑是否忘记处理 null 和 undefined