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