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

本文將探討mixin的缺點，并了解Composition API如何克服這些缺點，并使Vue應用程序更具可擴展性。

簡述Mixin

讓我們快速回顧一下mixin模式，因為它對于我們將在下一節(jié)中介紹的內(nèi)容至關(guān)重要。

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

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

當我們想要在組件之間共享相同的屬性時，可以將公共屬性提取到一個單獨的模塊中：

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

現(xiàn)在，我們可以通過將其分配給mixin配置屬性，將此mixin添加到任何使用它的組件中。在運行時，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 () { ... }
  }
}

Mixin被認為是“有害的”

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

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

命名沖突

我們看到了mixin模式如何在運行時合并兩個對象。如果它們都共享一個同名的屬性會發(fā)生什么？

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

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

這就是合并策略發(fā)揮作用的地方。這是一組規(guī)則，用于確定當組件包含多個同名選項時會發(fā)生什么。

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

即使我們不會遇到任何實際錯誤，但在多個組件和mixin之間處理命名屬性時，編寫代碼也會越來越困難。一旦添加了作為npm包的第三方mixin及其可能導致沖突的命名屬性，情況尤其困難。

隱式依賴

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

但這可能會導致問題。如果我們稍后想要重構(gòu)組件并更改mixin需要的變量的名稱會發(fā)生什么？從組件中我們不會注意到任何問題。代碼檢查器也不會發(fā)現(xiàn)它。我們只會在運行時看到錯誤。

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

從mixin遷移

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

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

直到現(xiàn)在。mixin的缺點是Composition API背后的主要動機因素之一。在了解它如何克服mixin問題之前，讓我們快速了解一下它的工作原理。

Composition API速成課程

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

這是一個使用Composition API定義的Vue 2組件的經(jīng)典示例，它定義了一個“計數(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
    }
  }
}

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

increment方法不是響應式的，因此可以將其聲明為普通的JavaScript函數(shù)。請注意，我們需要更改子屬性值才能更改count響應式變量的值。這是因為使用ref創(chuàng)建的響應式變量需要是對象才能在傳遞時保持其響應性。

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

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

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

代碼提取

Composition API的第一個明顯優(yōu)勢是易于提取邏輯。

讓我們使用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
  }
}

代碼重用

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

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

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

起初，這似乎有點冗長且毫無意義，但讓我們看看這種模式如何克服我們之前看到的mixin的問題。

命名沖突……已解決！

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

Composition API中不存在這個問題，因為我們需要顯式命名從組合函數(shù)返回的任何狀態(tài)或方法：

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

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

隱式依賴……已解決！

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

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

import useCompFunction from "./useCompFunction";

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

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

總結(jié)

mixin模式表面上看起來非常安全。但是，由于它增加了代碼的脆弱性以及它掩蓋了理解功能的能力的方式，通過合并對象來共享代碼成為了一種反模式。

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

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

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