来源:https://css-tricks.com
作者:Anthony Gore
想在你的vue组件之间共享代码?如果你熟悉 Vue 2 则可能知道使用 mixin ,但是新的 Composition api 提供了更好的解决方案。
在本文中,我们将研究mixins的缺点,并了解Composition API如何克服它们,并使Vue应用程序具有更大的可伸缩性。
让我们快速回顾一下mixins模式,因为对于下一部分我们将要讲到的内容,请务必将其放在首位。
通常,Vue组件是由一个JavaScript对象定义的,它具有表示我们所需功能的各种属性——诸如 data , methods , computed 等。
// MyComponent.js
export default {
data: () => ({
myDataProperty: null
}),
methods: {
myMethod () { ... }
}
// ...
}
当我们想在组件之间共享相同的属性时,可以将公共属性提取到一个单独的模块中:
// MyMixin.js
export default {
data: () => ({
mySharedDataProperty: null
}),
methods: {
mySharedMethod () { ... }
}
}
现在,我们可以通过将其分配给 mixin config属性将其添加到任何使用的组件中。在运行时,Vue会将组件的属性与任何添加的mixin合并。
// ConsumingComponent.js
import MyMixin from "./MyMixin.js";
export default {
mixins: [MyMixin],
data: () => ({
myLocalDataProperty: null
}),
methods: {
myLocalMethod () { ... }
}
}
对于这个特定的例子,在运行时使用的组件定义应该是这样的:
export default {
data: () => ({
mySharedDataProperty: null
myLocalDataProperty: null
}),
methods: {
mySharedMethod () { ... },
myLocalMethod () { ... }
}
}
早在2016年中期,丹·阿布拉莫夫(Dan Abramov)就写了《mixin被认为是有害的》(mixin Considered Harmful),他在书中辩称,将mixin用于在react组件中重用逻辑是一种反模式,主张远离它们。
不幸的是,他提到的关于React mixins的缺点同样适用于Vue。在了解Composition API如何克服这些缺点之前,让我们熟悉这些缺点。
我们看到了mixin模式如何在运行时合并两个对象。如果他们两个都共享同名属性,会发生什么?
const mixin = {
data: () => ({
myProp: null
})
}
export default {
mixins: [mixin],
data: () => ({
// 同名!
myProp: null
})
}
这就是合并策略发挥作用的地方。这是一组规则,用于确定当一个组件包含多个具有相同名称的选项时会发生什么。
Vue组件的默认(但可以配置)合并策略指示本地选项将覆盖mixin选项。Vue组件的默认(可选配置)合并策略指示本地选项将覆盖mixin选项。不过也有例外,例如,如果我们有多个相同类型的生命周期钩子,这些钩子将被添加到一个钩子数组中,并且所有的钩子都将被依次调用。
尽管我们不应该遇到任何实际的错误,但是在跨多个组件和mixin处理命名属性时,编写代码变得越来越困难。一旦第三方mixin作为带有自己命名属性的npm包被添加进来,就会特别困难,因为它们可能会导致冲突。
mixin和使用它的组件之间没有层次关系。这意味着组件可以使用mixin中定义的数据属性(例如mySharedDataProperty),但是mixin也可以使用假定在组件中定义的数据属性(例如myLocalDataProperty)。这种情况通常是在mixin被用于共享输入验证时出现的,mixin可能会期望一个组件有一个输入值,它将在自己的validate方法中使用。
不过,这可能会引起一些问题。如果我们以后想重构一个组件,改变了mixin需要的变量的名称,会发生什么情况呢?我们在看这个组件时,不会发现有什么问题。linter也不会发现它,我们只会在运行时看到错误。
现在想象一个有很多mixin的组件。我们可以重构本地数据属性吗?或者它会破坏mixin吗?我们得手动搜索才能知道。
从mixins迁移
mixin的替代方案,包括高阶组件,utility 方法和其他一些组件组成模式。
mixins的缺点是Composition API背后的主要推动因素之一,让我们快速了解一下它是如何工作的,然后再看它如何克服mixin问题。
Composition API的主要思想是,我们将它们定义为从新的 setup 函数返回的JavaScript变量,而不是将组件的功能(例如state、method、computed等)定义为对象属性。
以这个经典的Vue 2组件为例,它定义了一个“计数器”功能:
//Counter.vue
export default {
data: () => ({
count: 0
}),
methods: {
increment() {
this.count++;
}
},
computed: {
double () {
return this.count * 2;
}
}
}
下面是使用Composition API定义的完全相同的组件。
// Counter.vue
import { ref, computed } from "vue";
export default {
setup() {
const count = ref(0);
const double = computed(() => count * 2)
function increment() {
count.value++;
}
return {
count,
double,
increment
}
}
}
首先会注意到,我们导入了 ref 函数,该函数允许我们定义一个响应式变量,其作用与 data 变量几乎相同。计算属性的情况与此相同。
increment 方法不是被动的,所以它可以被声明为一个普通的JavaScript函数。注意,我们需要更改子属性 count 的 value 才能更改响应式变量。这是因为使用 ref 创建的响应式变量必须是对象,以便在传递时保持其响应式。
定义完这些功能后,我们将从 setup 函数中将其返回。上面两个组件之间的功能没有区别,我们所做的只是使用替代API。
Composition API的第一个明显优点是提取逻辑很容易。
让我们使用Composition API重构上面定义的组件,以使我们定义的功能位于JavaScript模块 useCounter 中(在特性描述前面加上“use”是一种Composition API命名约定。)。
//useCounter.js
import { ref, computed } from "vue";
export default function () {
const count = ref(0);
const double = computed(() => count * 2)
function increment() {
count.value++;
}
return {
count,
double,
increment
}
}
要在组件中使用该函数,我们只需将模块导入组件文件并调用它(注意导入是一个函数)。这将返回我们定义的变量,随后我们可以从 setup 函数中返回它们。
// MyComponent.js
import useCounter from "./useCounter.js";
export default {
setup() {
const { count, double, increment } = useCounter();
return {
count,
double,
increment
}
}
}
乍一看,这似乎有点冗长而毫无意义,但让我们来看看这种模式如何克服了前面讨论的mixins问题。
我们之前已经了解了mixin如何使用与消费者组件中的名称相同的属性,或者甚至更隐蔽地使用了消费者组件使用的其他mixin中的属性。
这不是Composition API的问题,因为我们需要显式命名任何状态或从合成函数返回的方法。
export default {
setup () {
const { someVar1, someMethod1 } = useCompFunction1();
const { someVar2, someMethod2 } = useCompFunction2();
return {
someVar1,
someMethod1,
someVar2,
someMethod2
}
}
}
命名冲突的解决方式与其他任何JavaScript变量相同。
前面还看到mixin如何使用在消费组件上定义的 data 属性,这可能会使代码变得脆弱,并且很难进行推理。
合成函数(Composition Function)还可以调用消费组件中定义的局部变量。不过,不同之处在于,现在必须将此变量显式传递给合成函数。
import useCompFunction from "./useCompFunction";
export default {
setup () {
// 某个局部值的合成函数需要用到
const myLocalVal = ref(0);
// 它必须作为参数显式地传递
const { ... } = useCompFunction(myLocalVal);
}
}
mixin模式表面上看起来很安全。然而,通过合并对象来共享代码,由于它给代码增加了脆弱性,并且掩盖了推理功能的能力,因此成为一种反模式。
Composition API最聪明的部分是,它允许Vue依靠原生JavaScript中内置的保障措施来共享代码,比如将变量传递给函数和模块系统。
这是否意味着Composition API在各方面都比Vue的经典API优越?不是的。在大多数情况下,你坚持使用经典API是没有问题的。但是,如果你打算重用代码,Composition API无疑是优越的。
在原生开发小程序的过程中,发现有多个页面都使用了几乎完全一样的逻辑。由于小程序官方并没有提供 Mixins 这种代码复用机制,所以只能采用非常不优雅的复制粘贴的方式去“复用”代码
除了核心功能默认内置的指令 (v-model 和 v-show),Vue 也允许注册自定义指令。注意,在 Vue2.0 中,代码复用和抽象的主要形式是组件。然而,有的情况下,你仍然需要对普通 DOM 元素进行底层操作,这时候就会用到自定义指令。
混入 (mixins) 是一种分发 Vue 组件中可复用功能的非常灵活的方式。混入对象可以包含任意组件选项。当组件使用混入对象时,所有混入对象的选项将被混入该组件本身的选项。组件和混入对象含有同名选项时,这些选项将以恰当的方式混合。
主要抽离组件共用的代码,如各个页面中分页组件的data、methods,和ui原型中统一的confirm和alert弹窗以及加载的进度条等
当我们的Vue项目功能越来越多时,如果有类似的组件,可能会发现自己一次又一次地复制和粘贴相同的数据、方法和 watch。当然,我们可以将所有这些单独的文件编写为一个单独的组件
Mixin 组件在项目中经常被用来重用一些业务逻辑,但它们有一些不确定的细微差别,这在项目开发中越来越明显。我偶尔也会遇到这种情况,它们会给代码库的重构或新功能的开发带来困难
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!