这个rfc我从开头一直在跟。我是新api的坚定支持者。新api本质上和react hooks没关系，就是看起来有点像，本质上就是以前 data computed watch methods 等东西换了个写法，把原来内部的功能函数暴露出来了，提供一个函数式的写法，不再suffer from this magic等等从前没法typing的老大难问题。按我的想法，vue的api从历史第一天就应该这么设计，那个山寨兮兮的object-based option api真是不科学。

然后，rfc下面某些反对者说的“高高在上优越感”的发言，其实基本都不是core team member。member们都在装孙子，是几个外围的rfc常客在不客气地各种怼，其中包括我。。

【 在 eGust (十年) 的大作中提到: 】
: 这个 rfc 跟前两天已经长得很不一样了，估计没人愿意翻历史，所以再补充点儿信息：
: 开始的时候，明确说 vue 2.x 的语法将在 v3 中 deprecated，预计在 v4 中移除，一听要移除大家就慌了。当然也包括我，毕竟在我的努力下新项目用了 vue，刚俩月就听说隔个两三年就得重写，这个让人不太好交代……还好周末过去，基本打消了这个顾虑。
: yyx 在 pr、推特中似乎还有过一些不太客气的说法，所以论坛上连 petulant、childish 这种词都出来了，不止一人对 vue 核心团队成员在讨论中高高在上的态度表达了不满……
: ...................
--
FROM 171.217.143.*

react和vue的核心区别是reactivity的实现方式。

理论上vue里面的computed watch也都不是必要概念，完全可以和react一样留给用户自己实现。父子之间的event传递也可以转化为函数prop的传递。

所以其实任何一个UI框架的核心概念也就是props和state嘛。本质区别还是怎么检测变动。react hooks搞得那么magical，就和react的检测机制有关。vue把检测放在了proxy/gett/setter层面，比较精细，所以vue开始做类似hooks的api的时候感觉更自然，更直观好理解。

第二个核心区别就是template vs jsx，当然我自己以前也是在vue里面写jsx的，不过大部分vue用户还是习惯template。我并不觉得会有很多人因为这个新api而转react，因为jsx不是每个人都能接受得了的。。。

【 在 eGust (十年) 的大作中提到: 】
: vue 的卖点在哪是另外一个话题了，但这场风波的核心跟新 api 一点儿关系都没有
: 不过我同意，如果跟 react 搞成一个样子的话，vue 就没什么优势了。毕竟 react 除去 lifecycle 只有 state、props 两个核心概念，跑到 vue 就变成了 data、computed、methods、watch 再加上 event 一共五个半概念了
--
FROM 171.217.143.*

n难保不会出现什么神奇bug，踩过好几次坑。当然不是vue的。其他各种包，哪怕是bugfix版本都有可能引入新bug

【 在 a0123456789q (a0123456789q) 的大作中提到: 】
: 2.6到2.7不是non-breaking incremental changes吗？
--
FROM 171.217.143.*

我觉得咱俩说的东西本质是一样的。

react为什么走functional单向数据流路线？不是因为它的props和state技术上无法被直接赋值修改，本质原因是因为它的reactivity机制是检测不到直接赋值的，所以必须走setState（）之类的显式触发，整体重新生成vdom然后diff。

vue的data为什么不需要setData（）？因为用了proxy/setter呗，所以也就没有必要非要使用单项数据流了。

说回现在这个新api，照样一点儿都不functional啊。不是说把object options改成了函数，就functional了。functional意味着无内部跨调用状态，无副作用，数据不可变，等等。vue的这套新函数api，包括react的hooks，都是在解决如何产生和管理副作用的问题，所以和“functional”毫无关系。

rfc里甚至明确说了，新的function-based api无法用于vue的functional component。

我觉得大家感受到的不适，主要是来自形式上从声明式的配置式api（旧对象api其实就是个配置文件一样的东西）变成了命令式一步步调用各种功能来初始化组件的api。这个很多人认为丑，不简洁，乱。

【 在 eGust (十年) 的大作中提到: 】
: 内部实现什么样，对使用者来说并不重要，暴露给用户的 api 才决定代码的组织形式。
: react 的形式是 functional 接口，数据的组织形式是单向的，整体概念上是一致的。
: vue 的组织形式可一点儿都不 functional，这点对不熟悉 fp 的用户是非常友好的。再加上 template 为主（我只在 storybook 里面用 jsx，因为实在不想专门写控件），导致不得不制造许多概念，才能满足代码复用的需求，比如 mixin、slot 什么的。
: ...................
--
FROM 171.217.142.*

是的你说的我都同意。reactivity方案的不同带来单向数据流，单向数据流又带来其他的好处（流程清晰，低心智负担）和坏处（啰嗦）。

【 在 eGust (十年) 的大作中提到: 】
: 我还是举一个例子吧，比如我们有这么一类 form 控件
: props: { target: Object, name: String, ... }
: computed: { value: { get() { return this.target[this.name] }, set ... } }
: ...................
--
FROM 171.217.142.*