Vue 3源码深度解析之：`Vue`的`HOC`（高阶组件）与`Composition API`的对比。

各位靓仔靓女，晚上好！今天咱们聊点Vue 3里面比较有意思的东西：高阶组件（HOC）和 Composition API，顺便看看它们之间的爱恨情仇。

开场白：什么是“高阶”？

先别被“高阶”这两个字吓到，其实它没那么玄乎。 就像高等数学，无非就是微积分再深入一点嘛（手动狗头）。在编程世界里，“高阶”一般指的是可以操作其他函数或者组件的函数或者组件。

• 高阶函数： 接收一个或多个函数作为参数，或者返回一个函数的函数。
• 高阶组件： 接收一个组件作为参数，返回一个新的、增强后的组件的组件。

今天咱们重点聊高阶组件，顺便拿它和 Composition API 对比一下，看看各自的优缺点。

第一幕：高阶组件（HOC）的前世今生

在Vue 2时代，HOC可是代码复用的一大利器。 想象一下，你需要给很多组件都加上一样的功能，比如登录验证、权限控制、日志记录等等。 如果每个组件都写一遍，那代码岂不是要爆炸？ HOC就是来拯救你的。

HOC的本质：一个函数，包装组件，返回新组件

本质上，HOC就是一个函数，它接收一个组件作为参数，然后返回一个新的、增强后的组件。 这个新组件通常会在原有组件的基础上，添加一些额外的 props、methods、或者生命周期钩子。

举个栗子：权限验证 HOC

假设我们有个withAuth函数，用来给组件加上权限验证的功能。

// withAuth.js
import { defineComponent } from 'vue';

const withAuth = (WrappedComponent, requiredRole) => {
  return defineComponent({
    data() {
      return {
        userRole: 'guest', // 模拟用户角色
      };
    },
    created() {
      // 模拟权限验证
      if (this.userRole !== requiredRole) {
        console.warn('权限不足，无法访问');
        // 可以在这里跳转到错误页面，或者显示一个错误提示
      }
    },
    render() {
      if (this.userRole === requiredRole) {
        return h(WrappedComponent, this.$attrs, this.$slots);
      } else {
        return h('div', '您没有权限访问该页面');
      }
    },
  });
};

export default withAuth;

这个withAuth函数接收两个参数：

• WrappedComponent: 需要进行权限验证的组件。
• requiredRole: 访问该组件需要的角色。

它返回一个新的组件，这个新组件会在created钩子中进行权限验证。 如果用户角色不符合要求，就显示一个错误提示。 如果符合要求，就渲染原始组件。

使用 HOC：

// MyComponent.vue
<template>
  <div>
    <h1>欢迎来到需要权限的页面</h1>
  </div>
</template>

<script>
import { defineComponent } from 'vue';
import withAuth from './withAuth';

export default withAuth(defineComponent({
  name: 'MyComponent',
}), 'admin'); // 需要 admin 权限
</script>

这样，MyComponent就被withAuth包装了一下，只有拥有admin权限的用户才能访问。

HOC 的优点：

• 代码复用： 多个组件可以共享同一个 HOC，避免重复编写代码。
• 逻辑分离： 将业务逻辑从组件中抽离出来，使组件更专注于渲染。
• 可组合性： 可以将多个 HOC 组合起来，实现更复杂的功能。

HOC 的缺点：

• props 冲突： HOC 可能会覆盖原始组件的 props，导致意想不到的问题。
• 命名冲突： HOC 可能会引入新的 props 或 methods，与原始组件的命名冲突。
• 层级过深： 多个 HOC 嵌套使用，可能会导致组件层级过深，影响性能。
• 类型推断困难： TypeScript 对 HOC 的类型推断支持不够友好，容易出现类型错误。

第二幕：Composition API 的横空出世

Vue 3 引入了 Composition API，旨在解决 Vue 2 Options API 在大型项目中代码复用和组织方面的一些问题。 Composition API 允许我们使用函数来组织组件的逻辑，而不是像 Options API 那样使用 data、methods、computed 等选项。

Composition API 的本质：函数式编程，拥抱变量，告别this

Composition API 的核心思想是：将组件的逻辑拆分成一个个独立的函数（通常称为 "Composables"），然后在 setup 函数中组合这些函数。 这样，我们就可以更容易地复用和组织组件的逻辑。

举个栗子：权限验证 Composables

还是权限验证的例子，用 Composition API 来实现：

// useAuth.js
import { ref, onMounted } from 'vue';

export default function useAuth(requiredRole) {
  const userRole = ref('guest'); // 模拟用户角色
  const hasPermission = ref(false);

  onMounted(() => {
    // 模拟权限验证
    if (userRole.value === requiredRole) {
      hasPermission.value = true;
    } else {
      console.warn('权限不足，无法访问');
      // 可以在这里跳转到错误页面，或者显示一个错误提示
    }
  });

  return {
    userRole,
    hasPermission,
  };
}

这个 useAuth 函数接收一个参数：

• requiredRole: 访问组件需要的角色。

它返回一个对象，包含：

• userRole: 用户角色。
• hasPermission: 是否拥有权限。

使用 Composables：

// MyComponent.vue
<template>
  <div>
    <div v-if="hasPermission">
      <h1>欢迎来到需要权限的页面</h1>
    </div>
    <div v-else>
      您没有权限访问该页面
    </div>
  </div>
</template>

<script>
import { defineComponent } from 'vue';
import useAuth from './useAuth';

export default defineComponent({
  name: 'MyComponent',
  setup() {
    const { userRole, hasPermission } = useAuth('admin'); // 需要 admin 权限

    return {
      userRole,
      hasPermission,
    };
  },
});
</script>

这样，MyComponent就使用了 useAuth Composables 来进行权限验证。

Composition API 的优点：

• 代码复用： 多个组件可以共享同一个 Composables，避免重复编写代码。
• 逻辑分离： 将业务逻辑从组件中抽离出来，使组件更专注于渲染。
• 可组合性： 可以将多个 Composables 组合起来，实现更复杂的功能。
• 类型推断友好： TypeScript 对 Composition API 的类型推断支持更好，不容易出现类型错误。
• 更好的可读性和可维护性： 使用函数来组织代码，更清晰易懂。

Composition API 的缺点：

• 学习成本： 需要学习新的 API 和编程模式。
• 心智负担： 需要自己管理状态，可能会增加心智负担。
• 过度抽象： 如果过度使用 Composables，可能会导致代码过于抽象，难以理解。

第三幕：HOC vs Composition API：巅峰对决

特性	HOC	Composition API
本质	函数，包装组件，返回新组件	函数式编程，拥抱变量，告别this
代码复用	优秀	优秀
逻辑分离	优秀	优秀
可组合性	良好，但容易导致组件层级过深	优秀，更灵活
类型推断	较差，容易出现类型错误	良好，类型安全
可读性和可维护性	较差，props 和命名冲突可能导致代码难以理解	良好，函数式编程更清晰易懂
适用场景	Vue 2 项目，需要对现有组件进行简单增强	Vue 3 项目，需要更灵活的代码复用和组织
坑	props 冲突、命名冲突、层级过深	学习成本、心智负担、过度抽象
例子	withAuth	useAuth

总结：

• HOC： 就像一个魔法盒子，把组件放进去，就能变出带新功能的组件。 但如果盒子太多，就容易迷路，而且盒子里的东西也容易打架。
• Composition API： 就像乐高积木，可以自由组合，搭建出各种各样的组件。 但如果积木太多，也需要好好规划，不然就容易搭成一堆乱七八糟的东西。

我的建议：

• 如果你的项目是 Vue 2，或者只需要对现有组件进行简单的增强，HOC 仍然是一个不错的选择。
• 如果你的项目是 Vue 3，或者需要更灵活的代码复用和组织，Composition API 是更好的选择。

最后的彩蛋：

其实，HOC 和 Composition API 并不是完全对立的。 在某些情况下，我们可以将它们结合起来使用。 比如，可以使用 HOC 来包装一个使用了 Composition API 的组件，从而实现更复杂的功能。

今天就到这里，希望大家对 HOC 和 Composition API 有了更深入的了解。 祝大家写代码 bug 越来越少，头发越来越多！ 拜拜！