在Vue組件間共享代碼？如果您熟悉Vue 2，您可能已經(jīng)使用過(guò)mixin來(lái)實(shí)現(xiàn)此目的。但是新的Composition API （現(xiàn)在可作為Vue 2的插件使用，並且是Vue 3的即將推出的功能）提供了一種更好的解決方案。

本文將探討mixin的缺點(diǎn)，並了解Composition API如何克服這些缺點(diǎn)，並使Vue應(yīng)用程序更具可擴(kuò)展性。

簡(jiǎn)述Mixin

讓我們快速回顧一下mixin模式，因?yàn)樗鼘?duì)於我們將在下一節(jié)中介紹的內(nèi)容至關(guān)重要。

通常，Vue組件由一個(gè)JavaScript對(duì)象定義，該對(duì)象具有各種屬性，表示我們需要實(shí)現(xiàn)的功能——例如數(shù)據(jù)、方法、計(jì)算屬性等等。

 // MyComponent.js
export default {
  data: () => ({
    myDataProperty: null
  }),
  methods: {
    myMethod () { ... }
  }
  // ...
}

當(dāng)我們想要在組件之間共享相同的屬性時(shí)，可以將公共屬性提取到一個(gè)單獨(dú)的模塊中：

 // MyMixin.js
export default {
  data: () => ({
    mySharedDataProperty: null
  }),
  methods: {
    mySharedMethod () { ... }
  }
}

現(xiàn)在，我們可以通過(guò)將其分配給mixin配置屬性，將此mixin添加到任何使用它的組件中。在運(yùn)行時(shí)，Vue會(huì)將組件的屬性與任何添加的mixin合併。

 // ConsumingComponent.js
import MyMixin from "./MyMixin.js";

export default {
  mixins: [MyMixin],
  data: () => ({
    myLocalDataProperty: null
  }),
  methods: {
    myLocalMethod () { ... }
  }
}

對(duì)於此特定示例，運(yùn)行時(shí)使用的組件定義如下所示：

 export default {
  data: () => ({
    mySharedDataProperty: null,
    myLocalDataProperty: null
  }),
  methods: {
    mySharedMethod () { ... },
    myLocalMethod () { ... }
  }
}

Mixin被認(rèn)為是“有害的”

早在2016年中期，Dan Abramov就撰寫(xiě)了“Mixins Considered Harmful”（認(rèn)為Mixin有害），其中他認(rèn)為在React組件中使用mixin來(lái)重用邏輯是一種反模式，主張避免使用它們。

不幸的是，他提到的關(guān)於React mixin的缺點(diǎn)也適用於Vue。在了解Composition API如何克服這些缺點(diǎn)之前，讓我們先了解一下這些缺點(diǎn)。

命名衝突

我們看到了mixin模式如何在運(yùn)行時(shí)合併兩個(gè)對(duì)象。如果它們都共享一個(gè)同名的屬性會(huì)發(fā)生什麼？

 const mixin = {
  data: () => ({
    myProp: null
  })
}

export default {
  mixins: [mixin],
  data: () => ({
    // 同名！
    myProp: null
  })
}

這就是合併策略發(fā)揮作用的地方。這是一組規(guī)則，用於確定當(dāng)組件包含多個(gè)同名選項(xiàng)時(shí)會(huì)發(fā)生什麼。

Vue組件的默認(rèn)（但可配置）合併策略規(guī)定局部選項(xiàng)將覆蓋mixin選項(xiàng)。不過(guò)也有例外。例如，如果我們有多個(gè)相同類型的生命週期鉤子，這些鉤子將被添加到鉤子數(shù)組中，並且所有鉤子都將按順序調(diào)用。

即使我們不會(huì)遇到任何實(shí)際錯(cuò)誤，但在多個(gè)組件和mixin之間處理命名屬性時(shí)，編寫(xiě)代碼也會(huì)越來(lái)越困難。一旦添加了作為npm包的第三方mixin及其可能導(dǎo)致衝突的命名屬性，情況尤其困難。

隱式依賴

mixin和使用它的組件之間沒(méi)有層次關(guān)係。這意味著組件可以使用mixin中定義的數(shù)據(jù)屬性（例如mySharedDataProperty），但mixin也可以使用它假定在組件中定義的數(shù)據(jù)屬性（例如myLocalDataProperty）。當(dāng)使用mixin來(lái)共享輸入驗(yàn)證時(shí)，這種情況很常見(jiàn)。 mixin可能期望組件具有一個(gè)輸入值，它將在自己的validate方法中使用該值。

但這可能會(huì)導(dǎo)致問(wèn)題。如果我們稍後想要重構(gòu)組件並更改mixin需要的變量的名稱會(huì)發(fā)生什麼？從組件中我們不會(huì)注意到任何問(wèn)題。代碼檢查器也不會(huì)發(fā)現(xiàn)它。我們只會(huì)在運(yùn)行時(shí)看到錯(cuò)誤。

現(xiàn)在想像一個(gè)包含許多mixin的組件。我們可以重構(gòu)局部數(shù)據(jù)屬性嗎，或者它會(huì)破壞mixin嗎？哪個(gè)mixin？我們必須手動(dòng)搜索所有mixin才能知道。

從mixin遷移

Dan的文章提供了mixin的替代方案，包括高階組件、實(shí)用程序方法和一些其他組件組合模式。

雖然Vue在許多方面與React相似，但他建議的替代模式並不能很好地轉(zhuǎn)換為Vue。因此，儘管這篇文章寫(xiě)於2016年中期，但Vue開(kāi)發(fā)人員從那時(shí)起就一直在忍受mixin問(wèn)題。

直到現(xiàn)在。 mixin的缺點(diǎn)是Composition API背後的主要?jiǎng)訖C(jī)因素之一。在了解它如何克服mixin問(wèn)題之前，讓我們快速了解一下它的工作原理。

Composition API速成課程

Composition API的關(guān)鍵思想是，與其將組件的功能（例如狀態(tài)、方法、計(jì)算屬性等）定義為對(duì)象屬性，不如將它們定義為從新的setup函數(shù)返回的JavaScript變量。

這是一個(gè)使用Composition API定義的Vue 2組件的經(jīng)典示例，它定義了一個(gè)“計(jì)數(shù)器”功能：

 //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.value * 2)
    function increment() {
      count.value ;
    }
    return {
      count,
      double,
      increment
    }
  }
}

您首先會(huì)注意到我們導(dǎo)入了ref函數(shù)，它允許我們定義一個(gè)響應(yīng)式變量，其功能與data變量幾乎相同。 computed函數(shù)也是如此。

increment方法不是響應(yīng)式的，因此可以將其聲明為普通的JavaScript函數(shù)。請(qǐng)注意，我們需要更改子屬性值才能更改count響應(yīng)式變量的值。這是因?yàn)槭褂胷ef創(chuàng)建的響應(yīng)式變量需要是對(duì)象才能在傳遞時(shí)保持其響應(yīng)性。

最好查閱Vue Composition API文檔以詳細(xì)了解ref的工作原理。

定義這些功能後，我們從setup函數(shù)返回它們。上面兩個(gè)組件的功能沒(méi)有區(qū)別。我們所做的只是使用了替代API。

提示： Composition API將成為Vue 3的核心功能，但您也可以在Vue 2中使用NPM插件@vue/composition-api。

代碼提取

Composition API的第一個(gè)明顯優(yōu)勢(shì)是易於提取邏輯。

讓我們使用Composition API重構(gòu)上面定義的組件，以便我們定義的功能位於JavaScript模塊useCounter中。 （使用“use”作為功能描述的前綴是Composition API的命名約定。）

 // useCounter.js
import { ref, computed } from "vue";

export default function () {
  const count = ref(0);
  const double = computed(() => count.value * 2)
  function increment() {
    count.value ;
  }
  return {
    count,
    double,
    increment
  }
}

代碼重用

要在組件中使用該功能，我們只需將模塊導(dǎo)入到組件文件中並調(diào)用它（注意導(dǎo)入是一個(gè)函數(shù)）。這將返回我們定義的變量，然後我們可以從setup函數(shù)返回這些變量。

 // MyComponent.js
import useCounter from "./useCounter.js";

export default {
  setup() {
    const { count, double, increment } = useCounter();
    return {
      count,
      double,
      increment
    }
  }
}

起初，這似乎有點(diǎn)冗長(zhǎng)且毫無(wú)意義，但讓我們看看這種模式如何克服我們之前看到的mixin的問(wèn)題。

命名衝突……已解決！

我們之前看到，mixin可以使用可能與使用組件中甚至更隱蔽地與使用組件使用的其他mixin中的屬性同名的屬性。

Composition API中不存在這個(gè)問(wèn)題，因?yàn)槲覀冃枰?em>顯式命名從組合函數(shù)返回的任何狀態(tài)或方法：

 export default {
  setup () {
    const { someVar1, someMethod1 } = useCompFunction1();
    const { someVar2, someMethod2 } = useCompFunction2();
    return {
      someVar1,
      someMethod1,
      someVar2,
      someMethod2
    }
  }
}

命名衝突將以與任何其他JavaScript變量相同的方式解決。

隱式依賴……已解決！

我們之前還看到，mixin可以使用使用組件上定義的數(shù)據(jù)屬性，這會(huì)使代碼變得脆弱且難以理解。

組合函數(shù)也可以調(diào)用使用組件中定義的局部變量。但是，區(qū)別在於現(xiàn)在必須將此變量顯式地傳遞給組合函數(shù)。

 import useCompFunction from "./useCompFunction";

export default {
  setup () {
    // 組合函數(shù)需要使用的某個(gè)局部值const myLocalVal = ref(0);

    // 它必須作為參數(shù)顯式傳遞const { ... } = useCompFunction(myLocalVal);
  }
}

總結(jié)

mixin模式表面上看起來(lái)非常安全。但是，由於它增加了代碼的脆弱性以及它掩蓋了理解功能的能力的方式，通過(guò)合併對(duì)象來(lái)共享代碼成為了一種反模式。

Composition API最巧妙之處在於它允許Vue依靠?jī)?nèi)置於原生JavaScript中的安全措施來(lái)共享代碼，例如將變量傳遞給函數(shù)和模塊系統(tǒng)。

這是否意味著Composition API在各個(gè)方面都優(yōu)於Vue的經(jīng)典API？不。在大多數(shù)情況下，您可以堅(jiān)持使用經(jīng)典API。但是，如果您計(jì)劃重用代碼，Composition API無(wú)疑是更好的選擇。

以上是VUE組成API如何替代Vue Mixins的詳細(xì)內(nèi)容。更多資訊請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！