Vue 3 Composition API——解决正确问题的错误方案

一见钟情

RFC 的一场闹剧

代码重用这一由来已久的问题

用错误的方法解决了正确的问题

一见钟情

2016年，我算是Vue.js的早期用户，我的第一个项目就是将一个现有的Vue 1应用移植到全新的Vue 2。作为一名React用户，我一开始持怀疑态度。我看到的是一个奇怪的混合体，它融合了从所有主流前端框架“窃取”来的各种功能。

然而，我几乎没花什么时间就彻底爱上了她。

这种“奇特的组合”似乎完美地平衡了 React 的灵活性、Angular 的结构化模块和 jQuery 的平缓学习曲线。

从那时起，我就成了 Vue 的早期推广者。我在我所在地区所有主要的 JavaScript 聚会上都做过关于 Vue 的演讲。我每年都去参加 Vue.js 阿姆斯特丹大会。

我在所有合适的项目中都使用了 Vue，但在很多情况下，它可能并不是合适的工具。甚至在 Vue 还没有移动端解决方案之前，我就已经开始使用 Cordova 开发混合 iOS 应用了。

RFC 的一场闹剧

然后，在2019年6月，RFC引发了一场轩然大波，当时Composition API被…… 宣布强加的。

在 GitHub、Hacker News 和 Reddit 上的激烈讨论中，我和核心团队成员之间发生了一些相当不愉快的互动。我和其他所有持不同意见的人都被告知，我们需要 React 风格的 hooks，因为所有的业务逻辑都必须放在组件中，而且他们最了解情况，因为这是他们的框架。

马丁·索蒂罗夫

@unclemartycodes

看到我最喜欢的前端框架VueJS向React风格的 Hooks 过渡得如此糟糕，真是令人难过。开源项目的沟通不应该是这样的。

2019年6月25日 上午7:21

0 3

最终，由于开发者们的强烈抗议，最初弃用旧组件语法的计划被放弃了，因此 v3 版本仍将支持我们喜爱的旧版 Vue 语法。太棒了！

代码重用这一由来已久的问题

组合式 API 的出现是为了解决由来已久的代码重用和业务逻辑封装问题。许多编程语言都是为了解决这个问题而诞生的，事实上，面向对象编程的整个学科都可以追溯到代码重用的愿景。

这个问题已经解决了，仅仅因为突然间可以在 JavaScript 文件中使用 CSS，并不意味着我们必须完全抛弃 30 年的编程知识，重新发明一切。

事实上，如果你阅读旧版本的 Vue.js 文档，你会发现它被宣传为 MVVM 设计模式（或Martin Fowler 最初称之为MVP ）中的 ViewModel 。

从技术角度来看，Vue.js 主要关注 MVVM 模式中的 ViewModel 层。它通过双向数据绑定连接 View 和 Model。

MVVM框架的目标从来都不是重用ViewModel！封装那些不与特定视图绑定的“无渲染”业务逻辑也不是。ViewModel的唯一职责是管理应用程序特定部分（单个组件）的状态。

值得庆幸的是，JavaScript 社区中仍然存在一些理智的声音，但遗憾的是，这些声音并没有被充分听到。

马丁·索蒂罗夫

@unclemartycodes

阿门！今天总得有人说这话，#VueJS和#JavaScript圈的人都把#设计模式和老旧的编码最佳实践抛到九霄云外了。什么无服务器、无渲染、模板里塞#GraphQL查询……😢 @jakecodes #vuejsamsterdam

2019年2月14日 下午4:50

3 7

用错误的方法解决了正确的问题

代码重用和业务逻辑封装当然是合理的问题，但将专注于应用程序视图层的技术强行改造以执行其他操作并不是正确的解决方案。

Composition API 据称可以解决以下问题：

• 混合料
• 无渲染组件
• 高阶分量

如果你必须使用某种组件继承，而将组件拆分或将公共功能提取到服务类中又不可行，那就意味着你的应用程序架构结构要么是错误的，要么 Vue.js 根本不适合这个项目。

Vue.js 并不是适用于所有用例的万能灵药，但这没关系。

令人遗憾的是，当 Vue.js 核心团队试图解决代码重用和业务逻辑封装这个由来已久的问题时，他们决定从 React 而不是 Angular 中寻找灵感。

在我看来，这破坏了 Vue.js 在 Angular 和 React 这两种截然相反的方法之间原本非常微妙的平衡，而这正是 Vue 最初吸引我们许多人的原因。