蓝瘦，想哭

我最近在死磕Vue 3的组合式API，说实话，虽然道理都懂，但写起来却非常难受。

蓝瘦主要表现有这么几点：

一、代码不像Vue 2那样被约束，写起来心累怎么办

尤雨溪观点：

首先说尤雨溪完全清楚这个问题，也承认有这个问题，选项式API有天然的代码约束，而组合式API没有天然的代码约束，但是他依然认为组合式API才是未来，尤雨溪支持组合式API的主要理由是，在大型的应用开发里，逻辑只有和用到的数据放在一起才更容易维护，这叫做“关注点分离”，这样可以提升可维护性，可维护性大于一切，而且不再有反复横跳现象。

我的观点：

我的观点绝对代表了一大批人的意见，我认为，这两种模式各有利弊，既然都说组合式API是未来，那么我主要说说组合式API的弊端。

1. 关于大型应用

如果大型应用的一个文件有几千行代码，那么你为什么不早早地分拆组件、拆分hook呢？在文件代码行数较少的前提下，我认为组合式API的优势并不明显。

2. 关于反复横跳

反复横跳确实存在，我认为横跳是一定会有的，谁找代码不是滚动滚轮到处找？选项式API是大横跳，组合式API是小横跳，都要跳。选项式API是滚动距离长，组合式API是滚动距离短，但是滚动距离长不代表用时长，毕竟滚动时间+人脑反应时间才是全部时间，选项式API的人脑反应时间并不长，有时还更短。只要你对代码区块位置形成固化记忆，并且用心给变量命名，这都不是问题。

对于代码区块位置形成固化记忆这个事，选项式API其实是有优势的，就是说，选项式API最大的特点就是“选项”，你可以把“选项”视为索引，根据索引去找代码，在遵循官方编写建议的前提下，你脑中已经明白，computed属性一定写在data属性的下方，watch属性又在computed属性的下方，methods属性又在watch属性的下方，生命周期夹在watch和methods之间，这些都相当于第一级分支，它们的属性是第二级分支。你对你要找的代码的大概位置很清楚。树状结构的终端就是各个变量，computed下面的终端变量一定是计算属性，一定确定以及肯定，无心智负担。

组合式API就不容易分这么细，毕竟它没有第一级分支的约束，比如你在2个data之间夹一个computed是完全可以的，这时你为了减少找代码的心智负担，你就总要整理各个变量的书写顺序，结果，就又成了选项式API的组织形式。另外，组合式API的最左侧只能看到一个个的let和const，然后你会看到变量名，从变量名，你无法一眼看出它是data还是computed，所以你的视线只能继续右移，看变量名后面的代码有没有computed字样，而选项式API，早在选第一级分支的时候我就看过了computed，它下面的一定是计算属性，毫无疑问。

对于用心给变量命名这个事，我意思是，请你让自己遵循比较严苛的命名法则，比如英文单词的单复数要敏感，事件函数写成onChangeXX、onClickOO的格式，例如我给<select>元素写事件，我肯定是写onChangeXX，我并不需要横跳确认。在遵守足够规则的前提下，你完全可以凭简单记忆就写出变量名和方法名，并不需要横跳去查变量名。

3. 关于选项式API的无尽的this

组合式API一出，一些人惊呼，终于摆脱无尽的this了！

我拜托，this这个关键字，从诞生以来就是为了简便开发，也不是JS独有，如果觉得this是“坏的”，倒不如说“编程语言都是垃圾”算了。

在选项式API里，我们只需要使用箭头函数，保证this始终指向Vue组件实例就好了，组件内数据方法皆在this下，我不知道这有什么不好。我不想多解释了。

4. 关于组合式API的hook解决了选项式API的mixins的痛点

这话确实没错，如果你的主组件需要分拆，mixins又多、又需要通信，那么，至少这个主组件是强烈推荐使用组合式API，哪怕你并不喜欢组合式API。

二、组合式API代码混乱怎么办

目前我的解决方案是使用2种范式。

范式一：采用hook

利用hook，你可以将全体代码拆分为若干个逻辑关注点，每个关注点写成一个hook，然后你可以有2种方式存放hook：

• 第一种方式，在主文件里拆分成几个hook函数。
• 第二种方式，主文件旁边建立若干个hook文件。

这时候，原本要return 20个变量，现在大约是拆成了3个hook，每个hook里return 7个变量，主文件会return 3个变量，这样可维护性更高。

范式二：主体用选项式API，setup()只引入和return hook，不处理逻辑

这是范式一的升级，是我目前采用的范式，至少2021年内我会始终采用这种范式，这种范式的优势是，避免Mixins的缺陷，也避免组合式API代码需要刻意维护代码区块的问题。

举个例子，先编一个hook文件：

import { ref } from "@vue/reactivity";

function hook1 () {
  let a = ref(false);
  function changeA() {
    a.value = !a.value;
  }
  return {a, changeA}
}

export default hook1;

主文件按照选项式API编写，setup()只负责返回hook，其他沿用Vue 2的编写方式：

import Hook1 from "../hooks/hook1";

export default {
  setup() {
    let useHook1 = Hook1();
    let useHook1Other = Hook1();
    return { useHook1, useHook1Other };
  },
  mounted() {
    this.useHook1.changeA();
    console.log(this.useHook1.a.value); // true
    this.useHook1Other.changeA();
    console.log(this.useHook1Other.a.value); // true
  },
};

同时，<template>里的变量由于有useHook1.、useHook1Other.前缀，也就形成了模块化。

三、定义一个响应式变量的时候，总会忘记引入vue方法怎么办

解决办法是，当你写完let a = ref，虽然ref只有3个字母，并不需要联想输入，但你此时依然应该敲一下Tab键，vetur插件会帮你创建import { ref } from 'vue'。reactive等同理。你并不需要提前写import { } from 'vue'。

四、总忘记在return里添加变量怎么办

并没有什么快捷方法让return {}中自动出现a,，只能手写。

五、return的变量太多，密密麻麻怎么办

确实，选项式API并不需要任何return，而且变量存放在各个分支（data、computed等）上，但是组合式API就需要return，而且是所有模板用得到的变量都需要return，导致data、computed、method全混在一起。

解决办法是：

1. 可以使用hook，使用之后，每个return的变量个数呈几何级减少，这是比较好的解决办法。

2. 另外，可以使用<script setup>，免去return，但是你要放弃选项式API。

六、总是忘记写ref对象的.value怎么办

可以使用<script setup>和ref:标签，但是你要放弃选项式API。

七、使用<script setup>时总忘记用ref:标签怎么办

那没办法，习惯就好。总之，.value和ref:你总要选择一样，看你的个人习惯吧。

八、解构导致失去响应式怎么办

用toRefs。

const {a,b,c} = toRefs(Proxy对象)

解决办法倒是简单，主要是要形成肌肉记忆，不要忘记。

九、对引用类型数据不知道用ref还是用reactive怎么办

如果后续打算重赋值变量，还不丢失响应式，那么用ref，如果后续只修改属性，那么用reactive。不确定未来会怎样的，先用reactive，未来再改。

总结：到底应不应该用组合式API，以什么原则定

1. 尽管组合式API更适合大型项目，但是你不要等到大型项目才开始接触Vue 3，那时候你真的会欲仙欲死，我建议你现在就开始学组合式API。

2. 你的第一个Vue 3上线项目应该使用选项式API，这样风险最低。之后可以将代码逐步重构成组合式API。在这个过程中，你就会有感悟，到底是组合式API还是选项式API更好？其实你可以根据每个组件的特点来定。

3. 拆分、复用是一门学问，要仔细体会。

4. 不要一味否认另一套API，就像我有时候也用函数式组件，也偶尔用JSX，该用就用。我建议你主打其中一种，副打另一种，不要一味只使用一种，在一个项目内出现两种API写法是正常的做法，在一个组件里出现两种写法也没问题，都是我推荐的做法。

5. 选项式API有它某些不可比拟的优势，尤雨溪不至于傻到几个版本之后彻底取消选项式API，所以，如果你打算主打选项式API，副打组合式API，有时候还混用，我认为没问题，就算几个大版本之后，选项式API消失了，也依然会有高手写出一个选项式API插件让你用，放心吧。如果到时候真的没有这种插件，说明选项式API确实是过时了，那时候相信你也早已习惯了组合式API，并且组合式API那时候已经有了更好的开发范式。