序文
2023年になり、vue3が誕生してから数年が経ちますが、依然としてvue2をベースにしたプロジェクトは数多くありますが、vue3のトレンドは避けられません ほとんどの人はvue2から学び、その後vue3を使用し、結合されたAPIにさらされてい
ますしかし、結合された API を理解していない人は、一見すると、「なんだ、めちゃくちゃだ、オプション API はとても優れている、メソッド変数は明確に分割されている」と思うでしょう。しかし、ほとんどの人にとっては、「みんなだから」が使っているので、私もそれに倣います。」
しかし、Vue3 を知らない同僚Composition Api
や、Vue を学んだばかりの初心者を助けに行くと、
相手は「なぜこれを使うのですか? とても面倒で面倒です。」と魂を痛めるような質問をするでしょう。
この記事では、2 つの API の違いと利点を比較して説明します
構成 API とは何ですか
公式ドキュメントを見てみましょう
Comboposition API は、オプションを宣言する代わりに関数を使用して Vue コンポーネントを作成できるようにする API のコレクションです。これは、以下の API をカバーする包括的な用語です。
- リアクティブ API : や などを使用すると
ref()
、reactive()
リアクティブな状態、計算されたプロパティ、およびリスナーを直接作成できます。 - ライフサイクル フック: や などを使用すると
onMounted()
、onUnmounted()
コンポーネントのさまざまなライフサイクル段階でロジックを追加できます。 - 依存関係注入: たとえば、リアクティブ API を使用するときに Vue の依存関係注入システムを利用できるようにします
provide()
。inject()
公式の画像と説明を見てみましょう
簡単に言うと、「コードはデータ、メソッド、計算などによって分割されるのではなく、ロジックに従って分割されます。以前は、この関数の関連ロジックを見つけるには、さまざまな切り替えやスクロールが必要でした。それを検索して使用していました。」 API を統合した後、母は関連するロジック コードが見つからないことを心配する必要がなくなり、コードを再編成することなくこのコードを他のファイルに移動できるようになりました。これにより、再構築のコストが大幅に削減され、コードの可読性が大幅に向上しました。コード。"
もちろん、結合した API がなぜこのように設計されているかを理解していないと、どんどん乱雑に書いてしまい、最終的にはクソの山になる可能性があります。現時点では、2 つの API の違いはクソの山です。カテゴリーに分けられるものとそうでないもの。
論理的な構成と再利用の向上
ではoptions Api
、ミックスインは基本的に、ロジックの再利用を実現するためのミックスインを作成するために使用され、options api
さらにさまざまなミックスイン インジェクションが行われ、その後、不可解にも this.xxxx() メソッドが調整されます。どこでどのファイルが this. メソッドを定義しているのかさえわかりません。しかし、フックを使用して mixin を置き換え、typescript を追加すると、データ ソースを追跡するのが非常に簡単になります。これは別の推奨フック ライブラリです、[vueuses]: https://vueuse.org/ もちろん、それを書くこともできますロジックの再利用の目的を達成するためのフック
たとえば、私の以前の記事の 1 つ:スクロール読み込み中のモバイルはフックで使用されています
公式ドキュメントには次のように記載されています: Vue 2 のユーザーはmixinsオプションに精通しているかもしれません。また、コンポーネント ロジックを再利用可能なユニットに抽出することもできます。ただし、ミックスインには 3 つの主な欠点があります。
- 不明確なデータ ソース: 複数のミックスインが使用されている場合、インスタンスのデータ属性がどのミックスインからのものであるかが不明確になり、実装を追跡してコンポーネントの動作を理解することが困難になります。これは、コンポーネントを使用するときにプロパティのソースを一目で明確にするために、合成関数で ref + 構造化パターンの使用を推奨する理由でもあります。
- 名前空間の競合: 異なる作成者の複数のミックスインが同じプロパティ名を登録し、名前の競合を引き起こす可能性があります。合成関数を使用する場合は、変数を構造化するときに変数の名前を変更することで、キー名が同一になることを避けることができます。
- 暗黙的なクロスミックスイン通信: 複数のミックスインは共有プロパティ名に依存して相互作用し、暗黙的に結合されます。結合関数の戻り値は、通常の関数と同様に、別の結合関数のパラメータとして渡すことができます。
上記の理由により、Vue 3 でミックスインを使用し続けることは推奨されなくなりました。この機能は、プロジェクト移行のニーズと、この機能に精通しているユーザーの対応のためにのみ残されています。
型推論の改善
公式説明:
近年、より堅牢で信頼性の高いコードを作成するためにTypeScriptを使用する開発者が増えており、TypeScript は非常に優れた IDE 開発サポートも提供します。ただし、オプションの API は 2013 年に設計されており、その時点では型の導出は考慮されていなかったため、オプションの API の型推定を実現するには、非常に複雑な型体操を行う必要がありました。しかし、これらすべての努力にもかかわらず、オプションの API の型推論は、ミックスインや依存関係注入型を扱う場合には依然として理想的ではありません。
したがって、TS で Vue を使用したい多くの開発者は、vue-class-component
が提供する Class API を使用します。ただし、クラスベース API は ES デコレータに大きく依存しており、2019 年に Vue 3 の開発を開始したとき、それはまだステージ 2 の言語機能でした。私たちは、不安定な言語提案に基づいてフレームワークのコア API を設計するリスクが大きすぎると考えているため、クラス API の方向で開発を継続していません。その後、デコレーターの提案は実際に多くの変更を経て、最終的に 2022 年にステージ 3 に到達しました。もう 1 つの問題は、クラスベースの API とオプションベースの API には、ロジックの再利用とコードの編成において同じ制限があることです。
対照的に、合成 API は主に、本質的に型に優しい基本的な変数と関数を利用します。合成 API で書き直されたコードは、型アノテーションをあまり書かなくても、完全な型推論を楽しむことができます。ほとんどの場合、TypeScript で記述されたコンポーザブル API コードは、JavaScript で記述されたコードとそれほど変わりません。これにより、多くの純粋な JavaScript ユーザーが IDE から一部の型推論機能を利用できるようになります。
簡単に言うと、TS サポートは非常にフレンドリーです。!兄弟!!ts を使用するのが好きな兄弟は、vue3+tsx の記述方法を直接使用でき、より快適です。
生産パッケージのサイズが小さくなる
フォームに記述されたコンポーネント テンプレートはインライン関数にコンパイルされ、のコードと同じスコープ内にあるComposition Api
ため、コード圧縮にさらに適しています。コンテキスト オブジェクトに依存してプロパティにアクセスするオプションの API とは異なり、コンパイルされたテンプレートは、インスタンスからプロキシすることなく、 で定義された変数に直接アクセスできます。<script setup>
<script setup>
this
<script setup>
Tree-Sharking のサポート: 無関係な依存関係を簡単に取り除くファイル内の従来のさまざまなグローバル マウントでは、マウントするものを使用しない場合でも、各コンポーネントが肥大化しますOptions Api
。main.js
もともとこれは混乱していて、どういうわけか、これに何かが定義されてマウントされている場所がわからなかったので、それを探す必要がありました。
書くのに便利
Vue3.2 以降のバージョンでは、セットアップ構文シュガーが追加され、
コンポーネントを宣言する必要がなくなりましたが、コンポーネントを宣言する必要がない場合は、リターンなしでOptions Api
グローバルに定義された変数にのみマウントできます。
これが問題を指していることを心配する必要はありません。reactive と一緒に使用すると、それが変数なのかメソッドなのかが一目でわかります。
要約する
Composition Api
プロジェクトの問題点のほとんどを解決しOptions Api
、保守性の高いコードを作成することは、常に全員の追求でした。自分が書いたプロジェクトを将来保守する人に叱られたくない人はいないでしょう。だから、一緒に受け入れましょうComposition Api
。