Architetural考慮事項：実装Vuex

Question

当社のフロントエンドのチームは現在、以下の機能とレポーティングアプリケーションに取り組んでいる：

• ダッシュボード
• ポートフォリオ分析ツールグリッドベースの結果を返します（検索フォーム私たちは、Vueの-CLI経由WebPACKのボイラープレート（）とVueJSを使用して設計しようとしている上に、建築家に決めました）
• 自動レポートページ

共通のコンポーネントを持っている：

• レポートコンポーネント
  • は、タイトル、説明、種類（グリッド、視覚化、など）と、いくつかの設定パラメータ
• レポートリストコンポーネント
  を持っています
  • プロパティとしてレポートコンポーネントのタイトルと配列があります。

一部要件格子状に配置されたレポートのリスト要素のアレイを有するダッシュボード

ダッシュボードコンポーネントは4つの以上のレポートリストコンポーネントを選択することができる複数の報告とそれぞれを有することができますレポートリスト選択メニューからユーザが見ることができます。各レポートコンポーネントには、ユーザーが操作して送信してレポートを再レンダリングできる1つ以上の設定パラメータを設定できます。レポートは、グリッド（ここではグリッド）またはビジュアライゼーションベースのレポートにすることができます。最後に、Auth0による認証もあります。

質問

• それはすべて私たちのコンポーネントおよび関連の相互作用のための状態を管理するためにVuexを使用する意味がありますか？
• アプリケーションがVuexの良いユースケースであるように聞こえますか？
• もしそうなら、なぜですか？親の子、兄弟兄弟のコンポーネントのための組み込みのVueメカニズムを介したコンポーネントからコンポーネントへの通信を使用するよりも優れていますか？

私たちが決定を下すのを助けてくれてありがとうございます。

Answer 1

Vuexは、同じ状態が必要な複数のコンポーネントがある場合に便利です。あなたのケースでは、さまざまな場所やフォーマットのレポートを表示しています。私の意見では、これはVuexの大きなユースケースです。

あなたのチームがVueに精通しているかどうかわかりませんが、小道具を介してデータを渡すのはPITAです。 特にの場合、データを必要とするコンポーネントがコンポーネント階層内に遠く離れて広がっていて、深くネストされていれば、通常はそうです。小道具を渡し、イベントを複数のレベルで出すことを夢中にしてきた人なら誰でもそれを伝えるでしょう。

Vuexでは、コンポーネント階層のどこからでも、データを取得するための単一の関数呼び出しです。新鮮な空気の息吹です。

Answer 2

私は答えが高く評価されているので、この質問を閉じるよう投票しました。

私はVueを使って複数のプロジェクトを構築しました。いくつかは数十のコンポーネントと数千のコード行を含んでいます。複雑さのレベルが私がVuexを必要としたレベルに上昇したことは一度も感じていません。

あなたは半ダースのコンポーネントでアプリケーションを説明しました。

私は論理をカスタムオブジェクトに抽象化しましたが、これは単なるjavascriptです。

YMMV。