VUE組成API如何替代Vue Mixins

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

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

簡述Mixin

讓我們快速回顧一下mixin模式，因為它對於我們將在下一節中介紹的內容至關重要。

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

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

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

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

現在，我們可以通過將其分配給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來重用邏輯是一種反模式，主張避免使用它們。

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

命名衝突

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

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

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

這就是合併策略發揮作用的地方。這是一組規則，用於確定當組件包含多個同名選項時會發生什麼。

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

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

隱式依賴

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

但這可能會導致問題。如果我們稍後想要重構組件並更改mixin需要的變量的名稱會發生什麼？從組件中我們不會注意到任何問題。代碼檢查器也不會發現它。我們只會在運行時看到錯誤。

現在想像一個包含許多mixin的組件。我們可以重構局部數據屬性嗎，或者它會破壞mixin嗎？哪個mixin？我們必須手動搜索所有mixin才能知道。

從mixin遷移

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

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

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

Composition API速成課程

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

這是一個使用Composition API定義的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.value * 2)
    function increment() {
      count.value ;
    }
    return {
      count,
      double,
      increment
    }
  }
}

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

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

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

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

提示： Composition API將成為Vue 3的核心功能，但您也可以在Vue 2中使用NPM插件@vue/composition-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.value * 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
    }
  }
}

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

命名衝突……已解決！

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

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

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

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

隱式依賴……已解決！

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

組合函數也可以調用使用組件中定義的局部變量。但是，區別在於現在必須將此變量顯式地傳遞給組合函數。

 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無疑是更好的選擇。

以上是VUE組成API如何替代Vue Mixins的詳細內容。更多資訊請關注PHP中文網其他相關文章！