Vue 3 Compsition APIはどのようにVue Mixinsを交換しますか？

6873 ワード

Vue 3 Compsition

あなたのVueコンポーネントの間でコードを共有したいですか？Vue 2に詳しいならmixinを使用することが分かりますが、新しいCompsition APIはより良い解決策を提供します。
本稿では、mixinsの欠点を研究し、Compsition APIがそれらをどのように克服し、Vueアプリケーションをより大きな伸縮性にするかを知る。
レビューMixins機能
早速mixinsモードを振り返ってみます。次の部分についてお話ししたい内容のため、ぜひトップに置いてください。
一般的に、VueコンポーネントはJavaScriptオブジェクトによって定義されています。これは私たちが必要とする機能を表す各種の属性を持っています。例えば、data、methods、computtedなどです。


// 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 () { ... }
 }
}

ミxinsは「有害」とされています。
2016年の中期には、ダン・アブモフ（Dan Abramov）が『mixinは有害と考えられている』（mixin Consinded Harmful）と書いており、ミxinをReactコンポーネントで再利用する論理は逆モードであると主張しています。
残念なことに、彼が指摘したReact mixinsの欠点はVueにも適用されます。Compsition APIがどのようにこれらの欠点を克服するかを知る前に、これらの欠点を熟知しましょう。
名前の衝突
私たちはmixinモードがどのように進行中に二つのオブジェクトを結合するかを見ました。二人が同じ名前の属性を共有するとどうなりますか？


const mixin = {
 data: () => ({
  myProp: null
 })
}

export default {
 mixins: [mixin],
 data: () => ({
  //   !
  myProp: null
 })
}

これが合併戦略が働くところです。これは同じ名前のオプションが一つのコンポーネントに複数含まれる場合に何が起こるかを決定するためのルールです。
Vueコンポーネントのデフォルトの統合ポリシーは、ローカルオプションがmixinオプションをカバーすることを示しています。Vueコンポーネントのデフォルトの統合ポリシーは、ローカルオプションがmixinオプションをカバーすることを示しています。例外もあります。例えば、同じタイプのライフサイクルのフックが複数あると、これらのフックは一つのフック配列に追加されます。そして、すべてのフックは順番に呼び出されます。
私たちは実際のエラーに出会うべきではないですが、複数のコンポーネントとmixinにまたがって命名属性を処理すると、コードの作成が難しくなります。第三者のmixinが自分の命名属性を持つnpmパッケージとして追加されると、衝突の原因となります。
陰的依存
mixinとそれを使ったコンポーネントの間には階層関係がない。これは、コンポーネントがmixinにおいて定義されたデータ属性（例えば、mySharedData Property）を使用することができることを意味するが、mixinは、コンポーネントにおいて定義されたと仮定したデータ属性（例えば、myLocalData Property）を使用してもよい。このような場合は通常、mixinが入力検証を共有するために用いられており、mixinは入力値が期待されるかもしれません。それは自分のvalidate方法で使用されます。
しかし、これはいくつかの問題を引き起こすかもしれません。もし私たちが後でコンポーネントを再構築したいなら、mixinに必要な変数の名前を変えたら、どうなりますか？私たちはこのコンポーネントを見ていますが、何か問題があるのかは分かりません。linterもそれを発見できません。運行中にしかエラーが見られません。
今はたくさんのmixinのセットがあると想像します。ローカルデータのプロパティを再構築できますか？それともmixinを破壊しますか？私たちは手動で検索しなければ分かりません。
mixinsから移転する
mixinの代替案は，高次コンポーネント，utility法および他のいくつかのコンポーネント構成モードを含む。
mixinsの欠点はCompsition APIの背後にある主な推進要因の一つであり、それがどのように働いているかを早く調べてみて、mixin問題をどうやって克服するかを見ましょう。
クイックエントリCompsition API
Compsition APIの主な考えは、これらを新しいsetup関数から返されるJavaScript変数と定義し、コンポーネントの機能（例えばstate、method、computtedなど）をオブジェクト属性として定義するのではない。
この古典的なVue 2コンポーネントを例にとって、カウンタ機能を定義します。


//Counter.vue
export default {
 data: () => ({
  count: 0
 }),
 methods: {
  increment() {
   this.count++;
  }
 },
 computed: {
  double () {
   return this.count * 2;
  }
 }
}

以下はCompsition 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を用いて作成された応答式変数は、転送時にその応答式を維持するためにオブジェクトである必要があるためである。
これらの機能を定義したら、セットアップ関数から戻ります。上の二つのコンポーネントの機能には違いがありません。私たちがやっているのは代替APIを使うだけです。
コード抽出
Compsition APIの最初の明白な利点は、抽出ロジックが容易であることである。
Compsition APIを使って上記で定義されたコンポーネントを再構成して、JavaScriptモジュールのuse Counterに定義された機能を配置します。


//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の属性をより隠蔽的に使用しているかを知りました。
これはCompsition APIの問題ではなく、任意の状態を明示的に命名するか、または合成関数から戻る方法が必要です。

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

名前の衝突の解決方法は他のJavaScript変数と同じです。
暗黙的依存…解決しました！
前にもmixinがどのように消費コンポーネントで定義されたdata属性を使うかを見ましたが、コードが弱くなり、推理が難しいです。
合成関数（Compsition Function）は、消費コンポーネントに定義された局所変数を呼び出すこともできる。しかし、異なる点は、この変数の明示的表現を合成関数に伝達しなければならないことである。


import useCompFunction from "./useCompFunction";

export default {
 setup () {
  //               
  const myLocalVal = ref(0);

  //             
  const { ... } = useCompFunction(myLocalVal);
 }
}

締め括りをつける
mixinモードは表面的には安全に見えます。しかし，コードは結合対象によって共有され，コードに脆弱性を増加させ，推理機能の能力を覆い隠すので，逆モードになる。
Compsition APIの最もスマートな部分は、Vueが元のJavaScriptに内蔵されている保障措置によってコードを共有することができます。たとえば変数を関数とモジュールシステムに渡すことです。
これはCompsition APIが各方面でVueの経典APIより優れているという意味ですか？いいえ、ちがいます。多くの場合、経典APIの使用を堅持するのは問題ないです。しかし、コードを再利用するつもりなら、Compsition APIは優れています。
ここで、Vue 3 Compsition APIがどのようにVue Mixinsを置き換えるかについての話を紹介します。Vue 3 CompsitionがVue Mixinsの内容を変えています。以前の文章を検索してください。または、下記の関連記事を引き続きご覧ください。これからもよろしくお願いします。