Vue 3.0 彻底跑偏了

我突然想起"求求你们别更新了,老子真是学不动了"这个贴子了

@wszgrcy 哈哈，ng 这么稳定、完成度高的框架，省了多少团队协作的成本，居然企业应用很少选择，搞不懂搞不懂

你这个“彻底”二字，我就想说你点什么

@plqws

> 则会让人纠结到底要用传统的 API 还是新 API
一般肯定是建议新代码新用法，老代码老用法。跟 React 生态的演进也没什么区别

> 开发者需要在 setup() 里到处寻找 value 在哪里，methods 在哪里，分辨哪些是 computed，某个叫做 isEnabled 的字段到底是 value 还是 computed
我不是太理解为什么需要区分 value 和 computed。
不过 value / computed 和 methods 的区分我觉得是可能会做出改进的（当前的 RFC 仍然是设计中的版本，不是最终版本，有新的好想法或好意见肯定会继续调整的）

> 可能会出现的旧 API 被废弃导致的迁移成本
RFC 里刚开始用了 deprecation 这个词，应该算是 Vue 团队信息传达时的一个失误，让普通用户被吓到了。
事实上，这个成本无限接近于零。
1. 因为 setup 写法是一个比较底层 /基础的实现，基于这上面提供旧 API 的兼容版本，不过是需要用户改一个 webpack alias，或者引入一个新的库而已（参考 create-react-class https://reactjs.org/docs/react-without-es6.html ），而维护这个兼容库的成本非常低
2. 另外因为 function API 的灵活性，其实这个代码可以低成本自动化转换（并且不丧失可读性）。Akryum 昨天差不多一天时间就写出了这样一个在线工具： https://suspicious-mclean-0e54c3.netlify.com/

> 不需要多熟悉 js 的语法糖或者未来特性，就能用 Vue 进行生产
函数也是非常基础的 JS 语法，而且去掉了魔改 this，应该说门槛更低了……

> 某种意义上，引入这个新的 API，基本上所有现存的插件都要重写
不，跟 React Hooks 相似，这只是提供了新的**底层**能力，现存插件完全可以不重写，只是说，新的底层能力让插件作者有可能设计出新的 API 用法。

@ragnaroks 我真的学不动了，作为一个后端开发来说，也要保持前端知识点的跟进真是学不动了

jQuery2 丢弃对旧版 IE 的支持，怎没见过那些 jQuery 程序员高呼跑偏呢？😒

#66 所以大伙还在用 jq1 呢

@sodatea #64 感谢回复。

不知道我这么理解对不对，function-based api 是一个底层的组件定义方式，并且可以支撑起 object-based component 甚至 class-based component 的实现。而 Vue 是打算将 object-based component 等支持拆分出去，作为可选内容？

从昨天下午开始我就一直翻阅那个 PR 的回复，目前看来，Vue 团队挺有必要写一篇文章，或者在 RFC 中专门说明这个内容，来缓解社区对这个提案的误解的加深，不过我看 Evan You 似乎也已经开始着手这件事了。

如果让组件 export default 一个函数（而不是一个 plain object ），由这个函数承载 setup() 的功能，并返回一个类似 Component Options 的东西让它看起来像 Vue 2.x 的写法，大家还会有这么大的抵触吗？

有 react 为啥用 Vue，悲哀。

Evan 说：你们先吵一会儿，我去给媳妇庆个生。

我不明白 React、Vue 这些为什么这么怕装饰器……没有装饰器的代码实在是太恶心了
UseUseUseUseUse
.value.value.value.value.value.value
还有各种一大坨的 Lamda 参数
看着就想吐

@df0618 有装饰器又说抄 angular 了

@martinoooo 所以之后打算去玩玩 angular 或者 Blazor 了，本来用 ts + vue class component +一个 vuex 装饰器组件 虽然有缺陷但感觉还挺好的，现在这种去 class 化应该是不会符合我的审美了

@plqws
是的。
解释工作应该在进行中了……

@df0618
1. API 设计上的权衡可以看这里： https://github.com/vuejs/rfcs/pull/17#issuecomment-494242121
2. JS 目前语言设计的问题，可以看下贺老的吐槽 <amp-youtube data-videoid="WDsEvlXE-BE" layout="responsive" width="480" height="270"></amp-youtube>JS 的 decorator 标准难产这么久不是没有原因的……依赖于这样的标准肯定是有风险的，作为用户层的 addon 更安全

学不动了，不要更新了

@sodatea #64
> 2. 另外因为 function API 的灵活性，其实这个代码可以低成本自动化转换（并且不丧失可读性）。Akryum 昨天差不多一天时间就写出了这样一个在线工具： https://suspicious-mclean-0e54c3.netlify.com/

其实我意识到了一个挺有意思的问题，从 options 转成 setup 的确挺简单的，因为 options 的结构和层次分明。但是如果要从 setup 转成 options 的话……好像没有什么头绪，因为写法太灵活了，做不了静态分析，不知道这意味着什么。

@hoosin react 难道不是一起领先于 vue 的吗

@rockyou12 问题大了去了。
1.C 的语法不够狗屎么。
一般人遇到能更狗屎的语法就是所谓的数学语言，但是数学好歹能在某个具体下游领域理直气壮地告诉你诸如“看这就是爱因斯坦求和约定老实看清楚别搞混不服闭嘴”；相比之下，C 的实现还是要缩卵到惦记某些用户记不住优先级规则而警告少括号，却又不敢在 spec 里不支持……高下立判。
2.看看，屎成这样都让你有底气“大部分”了。谁的锅？
现在还能抄这样子屎货设计的，大致情况是设计者脑子里没货和 /或被屎淹没不知所措弃疗了。