这是一个创建于 78 天前的主题，其中的信息可能已经有所发展或是发生改变。
早期是用的 js ，因为类型系统出了很多浪费时间的 bug ，后来迷迷糊糊用了大半年，以为一知半解了。
这几天开始撸这个 ts 的类型体操，简单的都撸的战战兢兢，汗如雨下，各位大神来挑战下：（它还有个 vscode 插件） https://github.com/type-challenges/type-challenges/blob/main/README.zh-CN.md
18 条回复 • 2024-08-31 00:11:37 +08:00
 |
1
kemf 78 天前
any 解决一切问题
|
 |
2
sampeng 78 天前  1
这个所谓的类型体操在我看起来就是炫技。技巧用得越多，后人（包括自己）在半年后再来看代码就跟看天书一样
|
 |
3
mshadow 78 天前 via Android
js 和 ts 完全是烂出了两个极端
|
 |
4
BeautifulSoap 78 天前
想给自己上强度就是这样的，
作为用 ts 写业务的后端，我每个项目都配好非常严格的 eslint ，然后写死编码风格 guideline 。基本上就是拿 ts 当 golang 和 java 来写。敢在项目里玩类型体操基本上 pr 我都是直接打回去，这样一套组合拳下去，至少项目代码是个人都能看懂了。也减少了成员作妖的几率 |
 |
5
guiyumin 78 天前
类型体操的话，如果你是自己维护一个 library ，让别人用，我觉得还可以
写业务，就别用类型体操了，不好维护，也没必要 |
 |
6
DOLLOR 78 天前
正常开发中，都是把 TS 当高级一点的注释来写的，基本没什么难度。
哪有在业务里玩类型体操的？ |
 |
7
kneo 78 天前 via Android
typescript 上限极高，有点自知之明。
|
 |
8
han3sui 78 天前
遇到难定义的类型，交给 gpt 比较省事
|
 |
9
lisxour 78 天前
ts 能这么花里胡哨也不一定说你都得会，能用个 20 种都很 ok 了，我看了这个 repo 的很多类型例子，一大半以上奇奇怪怪的类型都是没事找事，纯为了恶心自己而恶心自己，随便找个例子
 |
 |
10
forty 78 天前
稍微复杂一点的 ts 类型，我写不出来，也看不懂。尽量用简单的，不行就加点儿注释。
|
 |
11
penll 78 天前
使用 ts ，对自己是个提升。让自己多一种编程思想何尝不是大受益。
后续面对复杂的大项目，ts 不是得心应手。团队开发、风险控制等等 |
 |
12
IanHo 78 天前
还好吧，问问 gpt 就好了，以前没 gpt 要 google 才真烧脑
|
 |
13
WJYuan 78 天前
实际业务代码里不会有这么复杂的类型体操
|
 |
14
justdoit123 78 天前 1
别别别，业务代码真别用复杂体操。
TypeScript 你区分清楚哪些是 type ，哪些是 js 的代码就很阿弥佗佛了！日常用起来基本不会有什么问题。最低标准是一个逻辑单元对外的要有类型，对内实在没办法的地方就用 any 与 as 。没必要追求处处都要类型自洽。 进阶一点，知道 narrowing 、一些类型自动推导的逻辑即可。 类型体操，即便是写 lib 也不是太推荐用复杂的类型体操。太多次的变换、跳转，让用 lib 的人查起来也是很费力。 |
 |
15
wkj89 78 天前
后端仔表示：强类型 洒洒水啦
|
 |
16
huija 77 天前
类型体操无所谓，关键这玩意只能编译时骗骗自己。。
|
 |
17
HTML001 77 天前
我觉得 TS 适合做组件类的用，通用组件类用了 TS ，用起来顺心顺手。
但是业务代码用 TS 收益很低，有些复杂的内容，写起来恶心，维护起来更恶心（例如 9 楼那种），关键对代码的正向作用又很有限 |
 |
18
wjx0912 OP 感谢各位大佬。说的都很有道理。这下终于不纠结了~
|
Select Language