V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Imindzzz
V2EX  ›  TypeScript

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

  •  
  •   Imindzzz · 2021-07-28 10:36:16 +08:00 · 11664 次点击
    这是一个创建于 974 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

    大家心平气和不要吵架。

    124 条回复    2021-07-30 20:36:55 +08:00
    1  2  
    shik1
        101
    shik1  
       2021-07-29 10:23:32 +08:00
    ts 真的太香了!现在真不想碰 js 项目
    Highlights
        102
    Highlights  
       2021-07-29 10:23:52 +08:00
    @fanym 团队项目基本都是用框架开发的,但问题基本所有的前端都学过 js,学过 ts 的并不多,没有静态类型概念的连 interface 都理解不了,真不是所有人两下子就能上手的。
    Imindzzz
        103
    Imindzzz  
    OP
       2021-07-29 10:24:37 +08:00
    @ibegyourpardon
    一:把你的月抛周抛项目开源出来大伙看看,我倒要看看用 ts 能增加多少心智负担。
    恰恰是这种项目,这个月抛了,明年这个月又要叫你改改再上线一次,有 ts 不是更好改?
    Imindzzz
        104
    Imindzzz  
    OP
       2021-07-29 10:30:49 +08:00
    @Highlights 不是我看不起你哈,如果你的视野范围内是“学过 ts 的并不多”,那我劝你早点换个圈子,换个团队。
    或者你学好 ts,带着大伙一起用,提升整体的工作效率,年终奖就有着落了。
    (前面我也说到了,我想推推不动,来了个比我厉害的把各种事情安排好,大伙用得舒舒服服的。
    Highlights
        105
    Highlights  
       2021-07-29 10:40:15 +08:00   ❤️ 1
    @xd199153 去年推过,遭到全组的反对,算了,多谢您的指教,生活也可以这么轻松就好了,搬砖去了。
    libook
        106
    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
        107
    rongchuan  
       2021-07-29 11:11:19 +08:00
    想用就用,不想用就不用,这东西有用,但没那么大用,写起来成本也不低。我用 JS 十分钟能写完,换成 TS 要 20 分钟,何必呢。况且 VUE+TS 写起来一股异味,自己给自己造 bug,如果用 angular 的话写 TS 倒是无可厚非。至于说维护,你自己写的代码,要是你维护,那用不用 TS 没多大区别。要是维护别人的代码,别人用 TS 写的,你看起来会清楚一点,但也就清楚一点,不懂业务,你也看不懂他代码为啥这么写。
    要是 leader 要求大家写 TS,就老实写。leader 没发话,就别自我发挥了,浪费时间...这真不是啥高深的东西,写不写 TS 也没啥优越
    HAYWAEL
        108
    HAYWAEL  
       2021-07-29 11:30:47 +08:00
    @Highlights 这玩意还有反对的 ,做技术的,如果对新技术都不好奇,。
    Imindzzz
        109
    Imindzzz  
    OP
       2021-07-29 11:43:46 +08:00
    @rongchuan 把你“10 分钟”写完的项目开源出来看看,我看我用 ts 要不要 20 分钟。
    你要是真有什么“必须不用”的理由,那我没啥好说的。
    但是整个 js 生态(前端 /后端)都在推的东西,你是“可以可不用,所以我不用”,那我觉得你不是一个合格的工程师。
    Imindzzz
        110
    Imindzzz  
    OP
       2021-07-29 11:47:43 +08:00
    @libook 大伙至少都还是觉得“有提示更好”。看来自动推断也挺不错的,但不可否认还是 ts 更精确,重构也更方便。
    用 ts 都觉得麻烦(“有成本”)的话,用 jsdoc 不觉得更麻烦吗。。

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

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

    “尽快用上 ts,加入到这个生态圈里来” 应该是每个工程师的梦想吧?
    libook
        113
    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
        114
    Imindzzz  
    OP
       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
        115
    Imindzzz  
    OP
       2021-07-29 14:11:20 +08:00
    @libook 随便问一下,ts 我定义的对象参数,用 jsdoc 应该怎么定义? 我不会,所以图二写成了多个参数。
    libook
        116
    libook  
       2021-07-29 14:58:53 +08:00   ❤️ 1
    @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
        117
    leelz  
       2021-07-29 17:39:48 +08:00
    @xd199153 断断续续写了两年,光说后端反的一个大几十个字段的 json 去挨个定义类型就要花一会时间了。
    mxT52CRuqR6o5
        118
    mxT52CRuqR6o5  
       2021-07-29 17:42:10 +08:00 via Android
    @libook webstorm 里用重构工具能直接一次改好类型声明和代码声明
    libook
        119
    libook  
       2021-07-29 18:13:50 +08:00
    @mxT52CRuqR6o5 #118 是,TS 和 JS+doc 都能自动改。
    kingwl
        120
    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 。。。
    Imindzzz
        121
    Imindzzz  
    OP
       2021-07-30 17:40:07 +08:00
    @leelz
    两个方案,一个就是我前面说的,直接从返回数据里复制 json,不太优雅。
    一个是用接口文档生成代码,楼上也有说。
    Imindzzz
        122
    Imindzzz  
    OP
       2021-07-30 17:47:06 +08:00
    @kingwl 我觉得这个可以不用争了,我同意 @libook, 要实现大伙都能实现。

    只是我觉得现在圈子里大部分都用 ts,那就用 ts 更好吧,融入到 ts 打圈子里来。
    要迁移有成本的话,这个可以理解,
    94qihang
        123
    94qihang  
       2021-07-30 19:11:09 +08:00
    @xd199153 我寻思我也没说 TS 类型写着麻烦啊。
    我说的场景是:一个项目那么多接口,每个接口返回的数据结构都需要写类型定义;项目要求快速上线,这个时候还一定要用 TS 吗?虽然好多 API 文档工具都已经支持生成 TS 声明文件了,但是后端不配合你你怎么搞?
    我 18 年才开始用 TS,理解还不够深入,希望一块探讨吧。
    Imindzzz
        124
    Imindzzz  
    OP
       2021-07-30 20:36:55 +08:00
    @94qihang 你看一下我 12 楼 25 楼 121 楼,说的是不是你这个场景。

    写个 interface,然后 copy 一下接口的 json,这个花不了一分钟吧?
    要更详细的定义一下,也花不了几分钟吧?
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   989 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 21:58 · PVG 05:58 · LAX 14:58 · JFK 17:58
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.