サービス クラスを使用する従来のアプローチよりも Pinia/Vuex が好まれるのはなぜですか?

Question

パイナップル/牛

Pinia/Vuex および Redux は、「信頼できる唯一の情報源」となるように設計されており、どこからでも取得できるアプリケーション データを保持するストアを 1 つ以上持つことができます。

ピニアの店舗はこんな感じです:

リーリー

は次のように使用できます:

リーリー

複数のストアを作成できます:

リーリー

ストアは相互に参照できます:

リーリー

最後に、Pinia/Vuex は、状態に保存されたデータを取得および操作する機能を提供するツールです。

マネージャー/サービスクラス

しかし、もう 1 つの成熟したアプローチがあります。それは、マネージャー/サービス クラスです。

前の例は次のように書き換えることができます:

リーリー

これらはすべて、追加のラッパー (ref() など) を必要とせずに、TypeScript で簡単に入力できます。

＃＃＃話し合う＃＃＃

私が知る限り、Pinia は「車輪の再発明」のように見えます。同じ機能を不器用な方法で書いています。

さらに、依存関係の注入は提供されません。構成内のストアを初期化して、あるストアを別のストアに正確に注入することはできません。

useProductsStore()

などを渡す必要があります。 継承やその他の OOP も不可能です。

Pinia は循環依存関係さえも促進し、その結果、保守性の低いスパゲッティ コードが生成されます。

それでは、結局のところ、なぜマネージャー クラスを使用した実証済みのクリーンな OOP アプローチよりも Pinia/Vuex を好む必要があるのでしょうか?私は、「次に推奨される Vue の状態管理」として Pinia を使用して、自分で発明したチュートリアル プロジェクトを書くのに何十時間も費やしてきました。しかし、今では、Pinia が不格好でリッチだと思うので、すべてをマネージャー クラスに書き直したいという誘惑に駆られています。数年前、Vue2 を使用して別のテスト プロジェクトを作成していたことを思い出しました。そのときはマネージャー クラスを使用し、すべてがスムーズに進みました。何かを見落としていましたか？ピニアをやめたら何か問題はありますか？

Answer 1

クラスは Vue の反応性においては二級市民であり、落とし穴がいくつかあります。これらは コンストラクター内で this にバインドできません。その結果、非リアクティブ クラス インスタンスのリアクティブ プロキシが使用されます。これらの参照は 文書化されていますが、通常とは異なる方法で記述されているため、彼らは 参照を効果的に使用できません 。 get/set アクセサーを使用して参照を計算することはできません。これらの問題を解決するには、Vue リアクティブ API を明示的に使用して、奇妙な方法でクラスを作成するか、reactive(new MyClass) が正しく動作するのを妨げないように制限された方法でクラスを設計する必要があります。

クラスには、Vue 開発ツールやプラグイン システムなどの広範なサポートなど、ストアが備えている機能がありません。

クラスは JavaScript でもシリアル化できないため、状態の保存と復元には、ストレージ永続化プラグインのような単純な JSON (逆) シリアル化ではなく、カスタム ロジックが必要です。

依存関係の注入はクラスに固有のものではなく、Pinia ストアなどの適切な方法で実行できます。

リーリー

多くの場合、インスタンスを保存するよりもコンポーザブルを保存する Pinia を処理する方が適切です。これにより、コンポーザブルが時期尚早に呼び出された場合に問題となる循環依存関係が解決されます。同じ問題がクラスでも発生する可能性があり、クラス インスタンスを直接使用する代わりに DI コンテナを使用する必要があります。

再利用可能なコードはOOPではなくFPで扱えるため、継承に関しては問題ありません。 Vue はこれを明示的に推奨していませんが、前者をより慣用的で使いやすくしています。

TL;DR: これが Vue のリアクティブ設計の主なケースであるため、プレーン オブジェクトと FP を使用してください。