前端同学,你到现在还没用 typescript 原因是什么?

2021-07-28 10:36:16 +08:00
 Imindzzz

我认为使用 ts 是只有好处没有坏处的。因为实在没办法的时候也是可以降级到原生 js 的写法的,但是熟悉 ts 后那真是太爽了。

如果你有什么问题可以说出来,看大伙能不能给你一个完美的解决方案。

大家心平气和不要吵架。

13490 次点击
所在节点    TypeScript
124 条回复
shik1
2021-07-29 10:23:32 +08:00
ts 真的太香了!现在真不想碰 js 项目
Highlights
2021-07-29 10:23:52 +08:00
@fanym 团队项目基本都是用框架开发的,但问题基本所有的前端都学过 js,学过 ts 的并不多,没有静态类型概念的连 interface 都理解不了,真不是所有人两下子就能上手的。
Imindzzz
2021-07-29 10:24:37 +08:00
@ibegyourpardon
一:把你的月抛周抛项目开源出来大伙看看,我倒要看看用 ts 能增加多少心智负担。
恰恰是这种项目,这个月抛了,明年这个月又要叫你改改再上线一次,有 ts 不是更好改?
Imindzzz
2021-07-29 10:30:49 +08:00
@Highlights 不是我看不起你哈,如果你的视野范围内是“学过 ts 的并不多”,那我劝你早点换个圈子,换个团队。
或者你学好 ts,带着大伙一起用,提升整体的工作效率,年终奖就有着落了。
(前面我也说到了,我想推推不动,来了个比我厉害的把各种事情安排好,大伙用得舒舒服服的。
Highlights
2021-07-29 10:40:15 +08:00
@xd199153 去年推过,遭到全组的反对,算了,多谢您的指教,生活也可以这么轻松就好了,搬砖去了。
libook
2021-07-29 10:59:06 +08:00
@xd199153 #75 你这个例子不需要写 JSDoc,编辑器、IDE 能自己判断出有哪些属性或方法。https://imgtu.com/i/WH1KZF
任何编辑器、IDE 在没有 TS 插件的时候也都做不到 TS 的提示功能,相应的 JSDoc 带来的提示功能也是由插件实现的,和 TS 一样,很多编辑器和 IDE 自带了 JSDoc 的插件,甚至在 TS 出现之前就已经存在了。

其实更多区别还是在于类型声明上,这两张图就是个简单的对比,图一是 ESDoc 实现的,图二是 TS 实现的:
https://imgtu.com/i/WH3Ulq
https://imgtu.com/i/WH3Npn
你猜怎么着,ESDoc 还能给参数加描述。

建议看一下 JSDoc 和 ESDoc 的文档,在自己的编辑器或 IDE 上试试,花不了几分钟。

我觉得 TS 也就那样,没必要神化,项目适合就用,不适合就不用,TS 再怎么🐂🍺也不敢脱离 ES 的基本范畴,因为它就指着 ES 生态来维持用户群;除非某一天浏览器集体支持 TS 原生引擎,但只要 TS 还是微软主导的,就基本没可能。
rongchuan
2021-07-29 11:11:19 +08:00
想用就用,不想用就不用,这东西有用,但没那么大用,写起来成本也不低。我用 JS 十分钟能写完,换成 TS 要 20 分钟,何必呢。况且 VUE+TS 写起来一股异味,自己给自己造 bug,如果用 angular 的话写 TS 倒是无可厚非。至于说维护,你自己写的代码,要是你维护,那用不用 TS 没多大区别。要是维护别人的代码,别人用 TS 写的,你看起来会清楚一点,但也就清楚一点,不懂业务,你也看不懂他代码为啥这么写。
要是 leader 要求大家写 TS,就老实写。leader 没发话,就别自我发挥了,浪费时间...这真不是啥高深的东西,写不写 TS 也没啥优越
HAYWAEL
2021-07-29 11:30:47 +08:00
@Highlights 这玩意还有反对的 ,做技术的,如果对新技术都不好奇,。
Imindzzz
2021-07-29 11:43:46 +08:00
@rongchuan 把你“10 分钟”写完的项目开源出来看看,我看我用 ts 要不要 20 分钟。
你要是真有什么“必须不用”的理由,那我没啥好说的。
但是整个 js 生态(前端 /后端)都在推的东西,你是“可以可不用,所以我不用”,那我觉得你不是一个合格的工程师。
Imindzzz
2021-07-29 11:47:43 +08:00
@libook 大伙至少都还是觉得“有提示更好”。看来自动推断也挺不错的,但不可否认还是 ts 更精确,重构也更方便。
用 ts 都觉得麻烦(“有成本”)的话,用 jsdoc 不觉得更麻烦吗。。

“项目适合就用,不适合就不用”这话倒是没错啦,不过我也是一直强调“用 ts 没有坏处”嘛
就比如你这个 jsdoc 提示的场景,用 ts 就能免费得到这个功能(甚至更好),为啥不用呢~
kingwl
2021-07-29 11:50:47 +08:00
@libook 你猜你这三个截图的功能在 VSCode 里面是谁做的。。。
Imindzzz
2021-07-29 12:04:27 +08:00
@rongchuan 不好意思,“不是一个合格的工程师”说的有点激动了,抱歉。

我主要想表达的就是,你可以有各种理由暂时不能使用 ts,但是你不能否认 ts 对 前端(和 node 后端) 现代化 /工程化 /专业化... 的贡献。

“尽快用上 ts,加入到这个生态圈里来” 应该是每个工程师的梦想吧?
libook
2021-07-29 13:34:26 +08:00
@kingwl #111 你的意思是说,在 TS 出现之前没有任何工具可以做到这个事情吗? VSCode 使用的方案同时是其他所有编辑器和 IDE 使用的方案吗?讨论的问题是 JSDoc 、ESDoc 能否帮助达到 TS 一样的效果,这几张图不足以说明吗?


@xd199153 #110 仔细看我的图,用 doc 的方式除了能满足类型提示和检查以外还能加更多描述,很多时候团队协作为了写描述横竖都要写 doc,顺手写类型声明和 TS 的成本是一样的,也就只是写的位置不一样。

我前面的回复已经说明了,代码提示和类型检查都是工具带来的,TS 离了工具也没法出提示(用纯净的 Vim 试试看),面向 JS 的相关工具也都有,精确不精确取决于工具水平怎么样,WebStorm 上的高水平工具不写 JSDoc 靠推论也能做精准的类型提示。

工具链+语言,至少工具链方面 TS 并没有比 JS 多少优势,语言方面看你要约束还是要灵活,对于要灵活的情况来说,TS 的约束就是缺点。

技术栈选型从来都不是选一个最好的,而是选一个最合适的,任何技术都有优点和缺点,没有完美的。
Imindzzz
2021-07-29 14:09:34 +08:00
@libook 我说更精确,是下面这种。JSDoc 只能作为文档,不能限制工程师随手写错。
重构的时候,jsdoc 还是需要改注释和代码两个地方,调用方也不会报错(CI 测试照样会 pass)。
https://imgtu.com/i/WHqCgU
https://imgtu.com/i/WHqPvF

我觉得不需要争论 jsdoc 的类型好还是 ts 的类型,他们各司其职比较好。ts 提供精确的类型定义,jsdoc 提供详细的注释描述。
路图一,其实我一直都在写这种规范的注释,只是我不知道它叫“jsdoc”
Imindzzz
2021-07-29 14:11:20 +08:00
@libook 随便问一下,ts 我定义的对象参数,用 jsdoc 应该怎么定义? 我不会,所以图二写成了多个参数。
libook
2021-07-29 14:58:53 +08:00
@xd199153 #114 TS 重构的时候也是一样要改两个地方,一处类型声明、另一处代码声明,只不过这两个地方和 JS 的两个地方位置不一样而已。
工具都是有好用和不好用之分的,VSCode 的代码分析和提示功能跟一些商业 IDE 比起来还是很弱,在 WebStorm 里,JS 即便不写 doc 做类型声明也会通过代码分析来推断类型,然后给画波浪线,提交的时候还会提示代码可能存在问题建议去修改(也可以忽略),花的钱其实也值在这里。
无非是 TS 工具默认不忽略问题(你也可以 @ts-nocheck 忽略问题);这个对于 JS 工具来说也可以配置不忽略潜在问题,让 CI 直接失败。在这个问题上,不得不说 TS 技术栈给出的是一站式方案,包装成了现成的产品,开箱即用,而 JS 技术栈则依然十分灵活,按配置来实现需求。

对象参数用 doc 来定义的话有多种方式,一种思路是直接在 saveUser 声明参数的时候写个对象结构声明:
/**
* Save a user.
* @param {{nickname: string, age :number}} userObject
* @returns
*/
function saveUser(userObject) {
return true;
}

另一种思路可以先声明对象类型,然后在 saveUser 声明参数的时候直接引用这个类型,同样这种方式可以给每个属性写描述:
/**
* @typedef {Object} User
* @property {string} nickname
* @property {number} age
*/

/**
* Save a user.
* @param {User} userObject
* @returns
*/
function saveUser(userObject) {
return true;
}
// 效果如此: https://imgtu.com/i/Wb9wY4


JSDoc 和 ESDoc 是两种 doc 标准,前者主要针对原型写法,后者主要针对 class 写法(这么说也比较笼统),不过很多工具都是会同时集成两者,都可以直接用,也确实有很多人不知道有这个东西,在 TS 出现之前 JSDoc 是解决文档和辅助语法检查问题的主要方式之一。
leelz
2021-07-29 17:39:48 +08:00
@xd199153 断断续续写了两年,光说后端反的一个大几十个字段的 json 去挨个定义类型就要花一会时间了。
mxT52CRuqR6o5
2021-07-29 17:42:10 +08:00
@libook webstorm 里用重构工具能直接一次改好类型声明和代码声明
libook
2021-07-29 18:13:50 +08:00
@mxT52CRuqR6o5 #118 是,TS 和 JS+doc 都能自动改。
kingwl
2021-07-30 15:41:25 +08:00
@libook

是,但不完全是。例如:

```ts

/**
* @template {string} T
* @param {T} x
* @return {T}
*/
function strindId(x) {
return x;
}

const a = strindId(1); // Argument of type 'number' is not assignable to parameter of type 'string'.
const b = strindId("");

```

除非有人 /公司另外实现了一个 TS typechecker, 否则最后还是交给了 TS 。。。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/792205

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX