但前端项目的版本更新太快了。打包的代码模板很快社区就不维护了。往里面加组件只能自己扣。

【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 重要的项目一般都会锁依赖版本的吧。。。从2.6升到2.7都不敢，何况2升到3
: 不管最前沿发展到啥版本了，稳定性要求高的历史悠久项目肯定不敢追新，乖乖继续在旧版本依赖上做增量式开发。唯一的问题就是如果落后太多版本的话，社区里面现成可用的新插件轮子往往没法直接用，得改改。。
--
修改:hgoldfish FROM 183.253.23.*
FROM 183.253.23.*

内部实现什么样，对使用者来说并不重要，暴露给用户的 api 才决定代码的组织形式。

react 的形式是 functional 接口，数据的组织形式是单向的，整体概念上是一致的。

vue 的组织形式可一点儿都不 functional，这点对不熟悉 fp 的用户是非常友好的。再加上 template 为主（我只在 storybook 里面用 jsx，因为实在不想专门写控件），导致不得不制造许多概念，才能满足代码复用的需求，比如 mixin、slot 什么的。

再延伸出去就是 react + redux vs vue + vuex 的问题。redux 可以说概念十分的简单，只要掌握了 immutable、pure function 就不会出错，跟 react 的思路是一致的。而 vuex 有点儿奇怪的，state - data，getter - computed，同步更新 mutation、异步 action - method，看起来一一对应，但 state 其实是 functional，只能读、走 action 更新。这与 data、computed { get, set } 是格格不入的，所以新手很容易用错。似乎说过下个版本要简化 vuex 接口，不知道会不会对新手更友好些

【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: react和vue的核心区别是reactivity的实现方式。
: 理论上vue里面的computed watch也都不是必要概念，完全可以和react一样留给用户自己实现。父子之间的event传递也可以转化为函数prop的传递。
: 所以其实任何一个UI框架的核心概念也就是props和state嘛。本质区别还是怎么检测变动。react hooks搞得那么magical，就和react的检测机制有关。vue把检测放在了proxy/gett/setter层面，比较精细，所以vue开始做类似hooks的api的时候感觉更自然，更直观好理解。
: ...................
--
FROM 125.238.192.*

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

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.*

我还是举一个例子吧，比如我们有这么一类 form 控件
props: { target: Object, name: String, ... }
computed: { value: { get() { return this.target[this.name] }, set ... } }

父控件把 data 中的对象和名称传给子控件，<child :target="foo" name="bar" />，子控件使用 v-model="value"，然后在 set 里做比较，决定要不要放入待传回的数据中。上周同事问了我一个问题，为什么明明我在父控件里 this.foo.bar = baz，结果这个字段却没出现？他期待子控件 computed.value.set 会被调用……

如果用 react，父控件不得不再传一个调用 setState 的方法进去，更新之后的 target 也是一个全新的对象，你觉得还能问出来这种问题么？

react 故意设计成所有的对象都应该 immutable，想有属性变化就得重新生成一个，这样你不得不去关注数据的流向。vue 的做法的确是 gc 压力小了，上 proxy 之后效率比生成新对象高更多了。但是双向数据绑定的弊病也出来了：多个源都可以去更新同一个对象，数据的流向变得难以追踪。

还是老话，对于使用者来说，并不在意内部实现是怎样的。vue 比 react 加载快了多少，内存少占用多少，复杂的页面能多画几帧，并不是那么重要。跟正确性相比，代码写得更费劲、效率低了，都不是大的问题。java 跟 c++ 比起来，不光跑得慢，还更啰嗦（不造轮子的话），但是人家不容易啰嗦错啊。

【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 我觉得咱俩说的东西本质是一样的。
: react为什么走functional单向数据流路线？不是因为它的props和state技术上无法被直接赋值修改，本质原因是因为它的reactivity机制是检测不到直接赋值的，所以必须走setState（）之类的显式触发，整体重新生成vdom然后diff。
: vue的data为什么不需要setData（）？因为用了proxy/setter呗，所以也就没有必要非要使用单项数据流了。
: ...................
--
修改:eGust FROM 125.238.192.*
FROM 125.238.192.*

做业务的，尤其是前端业务，对新功能需求敏感，很多时候就是为了新功能而升级。

开源流行之后，还能有多少历史悠久的玩意能能产生对代码稳定性的需求。

还不是产品经理动动嘴，码农忙得抬不动腿。

【 在 beep 的大作中提到: 】
: 重要的项目一般都会锁依赖版本的吧。。。从2.6升到2.7都不敢，何况2升到3
: 不管最前沿发展到啥版本了，稳定性要求高的历史悠久项目肯定不敢追新，乖乖继续在旧版本依赖上做增量式开发。唯一的问题就是如果落后太多版本的话，社区里面现成可用的新插件轮子往往没法直接用，得改改。。
:
--
FROM 45.117.99.*