浅谈Vue3 Composition API如何替换Vue Mixins
想在你的Vue组件之间共享代码？如果你熟悉Vue2则可能知道使用mixin，但是新的CompositionAPI提供了更好的解决方案。
在本文中，我们将研究mixins的缺点，并了解CompositionAPI如何克服它们，并使Vue应用程序具有更大的可伸缩性。
回顾Mixins功能
让我们快速回顾一下mixins模式，因为对于下一部分我们将要讲到的内容，请务必将其放在首位。
通常，Vue组件是由一个JavaScript对象定义的，它具有表示我们所需功能的各种属性——诸如data，methods，computed等。
//MyComponent.js
exportdefault{
data:()=>({
myDataProperty:null
}),
methods:{
myMethod(){...}
}
//...
}
当我们想在组件之间共享相同的属性时，可以将公共属性提取到一个单独的模块中：
//MyMixin.js
exportdefault{
data:()=>({
mySharedDataProperty:null
}),
methods:{
mySharedMethod(){...}
}
}
现在，我们可以通过将其分配给mixinconfig属性将其添加到任何使用的组件中。在运行时，Vue会将组件的属性与任何添加的mixin合并。
//ConsumingComponent.js
importMyMixinfrom"./MyMixin.js";
exportdefault{
mixins:[MyMixin],
data:()=>({
myLocalDataProperty:null
}),
methods:{
myLocalMethod(){...}
}
}
对于这个特定的例子，在运行时使用的组件定义应该是这样的：
exportdefault{
data:()=>({
mySharedDataProperty:null
myLocalDataProperty:null
}),
methods:{
mySharedMethod(){...},
myLocalMethod(){...}
}
}
Mixins被认为“有害”
早在2016年中期，丹·阿布拉莫夫(DanAbramov)就写了《mixin被认为是有害的》(mixinConsideredHarmful)，他在书中辩称，将mixin用于在React组件中重用逻辑是一种反模式，主张远离它们。
不幸的是，他提到的关于Reactmixins的缺点同样适用于Vue。在了解CompositionAPI如何克服这些缺点之前，让我们熟悉这些缺点。
命名冲突
我们看到了mixin模式如何在运行时合并两个对象。如果他们两个都共享同名属性，会发生什么？
constmixin={
data:()=>({
myProp:null
})
}
exportdefault{
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的缺点是CompositionAPI背后的主要推动因素之一，让我们快速了解一下它是如何工作的，然后再看它如何克服mixin问题。
快速入门CompositionAPI
CompositionAPI的主要思想是，我们将它们定义为从新的setup函数返回的JavaScript变量，而不是将组件的功能（例如state、method、computed等）定义为对象属性。
以这个经典的Vue2组件为例，它定义了一个“计数器”功能：
//Counter.vue
exportdefault{
data:()=>({
count:0
}),
methods:{
increment(){
this.count++;
}
},
computed:{
double(){
returnthis.count*2;
}
}
}
下面是使用CompositionAPI定义的完全相同的组件。
//Counter.vue
import{ref,computed}from"vue";
exportdefault{
setup(){
constcount=ref(0);
constdouble=computed(()=>count*2)
functionincrement(){
count.value++;
}
return{
count,
double,
increment
}
}
}
首先会注意到，我们导入了ref函数，该函数允许我们定义一个响应式变量，其作用与data变量几乎相同。计算属性的情况与此相同。
increment方法不是被动的，所以它可以被声明为一个普通的JavaScript函数。注意，我们需要更改子属性count的value才能更改响应式变量。这是因为使用ref创建的响应式变量必须是对象，以便在传递时保持其响应式。
定义完这些功能后，我们将从setup函数中将其返回。上面两个组件之间的功能没有区别，我们所做的只是使用替代API。
代码提取
CompositionAPI的第一个明显优点是提取逻辑很容易。
让我们使用CompositionAPI重构上面定义的组件，以使我们定义的功能位于JavaScript模块useCounter中（在特性描述前面加上“use”是一种CompositionAPI命名约定。）。
//useCounter.js
import{ref,computed}from"vue";
exportdefaultfunction(){
constcount=ref(0);
constdouble=computed(()=>count*2)
functionincrement(){
count.value++;
}
return{
count,
double,
increment
}
}
代码重用
要在组件中使用该函数，我们只需将模块导入组件文件并调用它（注意导入是一个函数）。这将返回我们定义的变量，随后我们可以从setup函数中返回它们。
//MyComponent.js
importuseCounterfrom"./useCounter.js";
exportdefault{
setup(){
const{count,double,increment}=useCounter();
return{
count,
double,
increment
}
}
}
乍一看，这似乎有点冗长而毫无意义，但让我们来看看这种模式如何克服了前面讨论的mixins问题。
命名冲突解决了
我们之前已经了解了mixin如何使用与消费者组件中的名称相同的属性，或者甚至更隐蔽地使用了消费者组件使用的其他mixin中的属性。
这不是CompositionAPI的问题，因为我们需要显式命名任何状态或从合成函数返回的方法。
exportdefault{
setup(){
const{someVar1,someMethod1}=useCompFunction1();
const{someVar2,someMethod2}=useCompFunction2();
return{
someVar1,
someMethod1,
someVar2,
someMethod2
}
}
}
命名冲突的解决方式与其他任何JavaScript变量相同。
隐式依赖…解决了！
前面还看到mixin如何使用在消费组件上定义的data属性，这可能会使代码变得脆弱，并且很难进行推理。
合成函数(CompositionFunction)还可以调用消费组件中定义的局部变量。不过，不同之处在于，现在必须将此变量显式传递给合成函数。
importuseCompFunctionfrom"./useCompFunction";
exportdefault{
setup(){
//某个局部值的合成函数需要用到
constmyLocalVal=ref(0);
//它必须作为参数显式地传递
const{...}=useCompFunction(myLocalVal);
}
}
总结
mixin模式表面上看起来很安全。然而，通过合并对象来共享代码，由于它给代码增加了脆弱性，并且掩盖了推理功能的能力，因此成为一种反模式。
CompositionAPI最聪明的部分是，它允许Vue依靠原生JavaScript中内置的保障措施来共享代码，比如将变量传递给函数和模块系统。
这是否意味着CompositionAPI在各方面都比Vue的经典API优越？不是的。在大多数情况下，你坚持使用经典API是没有问题的。但是，如果你打算重用代码，CompositionAPI无疑是优越的。
到此这篇关于浅谈Vue3CompositionAPI如何替换VueMixins的文章就介绍到这了,更多相关Vue3Composition替换VueMixins内容请搜索毛票票以前的文章或继续浏览下面的相关文章希望大家以后多多支持毛票票！