2017-01-13 3 views
2

純粋なVueアプリケーションをVuexに移行しています。データを下流のコンポーネントに渡す最善の方法についてはわかりません。 Vueの道をプロパティとして渡す方法です:Vuex:店舗に直接アクセスするか、プロパティを渡すか?

<component :my-prop="myProp"/> 

Vuexの方法は、直接ストアにアクセスしているようだ:

computed: { 
    myProp: function() { 
     return this.$store.state.myProp; 
    } 
} 

はVuexの方法は、結合するためにビュー(コンポーネント)傾向がありませんデータ(ストア)レイヤーをより緊密にすることができますか?一方、下流のプロパティを渡すことは少し痛みを伴うことがあります。

Vuexでストアデータにアクセスするには、どのような方法が推奨されますか?

答えて

1

私は個人的にはプロパティを使用することをお勧めします。このようにして、コンポーネントを店舗から切り離します。例えば。あなたのコンポーネントは(他のプロジェクトで、後でなどで)再利用でき、依存関係としてストアを持っていません。

店舗が変更された場合。 VueXの新しいバージョン、後で別のベストプラクティス、親だけが変更する必要がある、すべてのコンポーネントは同じように動作します。

+0

しかし突然変異はどうですか?コンポーネントがストア状態をプロパティとして受け取り、それに突然変異を適用する必要がある場合、コンポーネントはグローバルストアにアクセスする必要があります。店舗全体(store.stateではなく)をコンポーネントに渡す必要がありますか? – Charles

+0

@Charles店舗全体を渡すのは無意味です。また、子コンポーネントは決してその小道具を変更するべきではありません。私の答えをチェックしてコンセプトを得るなら、これは質問ではありません。 – CodinCat

+0

コンポーネントはどのようにしてコンポーネントからストアの突然変異を引き起こすと思われますか?$ store.dispatch( 'refreshSomething')、データはプロパティとして渡されますか?まだカップルのコンポーネント/ストア一緒に、それではないですか? – Charles

-1

vuexストアのすべてを保存する必要はありません。あなたはまだコンポーネントデータを持ち、それらを小道具を介して子コンポーネントに渡すことができます。 、

状態が他のコンポーネントと共有する必要はありません、またはコンポーネントがアンマウントされたときの状態を維持する必要がない場合:

はここでReduxのために同じ質問の私の他の答えですそれをコンポーネントの状態に入れるだけです。

vuexストアはフロントエンドのデータベースだと考えることができます。APIから製品データをフェッチした場合は、vuexストアが適切な場所にあります。 isOpen小道具を使用するドロップダウンコンポーネントがある場合、そのドロップダウンの親はdropdownIsOpenをコンポーネントの状態として保持できます。

基本的には同じ考えです。コンテナコンポーネントとプレゼンテーションコンポーネントの2種類があります。

コンテナコンポーネントは、vuexストアに直接アクセスします。プレゼンテーションコンポーネントはvuexについて何も知る必要はなく、小道具しか受け取らないので、簡単に再利用できます。

+0

私はチャールズがあなたが店の中にプロダクトのようなものを持っていて、そのコンポーネントがそのプロダクトのフォームエディタであるという事件を尋ねていると思います。プロダクトがプロパティを介して渡されるか、子コンポーネント内のストアから直接取り出されるべきかどうか。 – SteveEdson

+0

これらの質問の背後にあるコンセプトは同じです。コンポーネントの状態とグローバルストアの選択方法また、コンポーネントベースのシステムの設計にも関連します – CodinCat

+0

製品の場合、フォームエディタはコンテナ(スマート)コンポーネントであるため、ストアデータに直接アクセスして変更することができます。小道具を介して店を渡すことは理にかなっていません。 – CodinCat

1

質問に記載されているように、親のデータを取得してからpropとすると、少し痛いことがあります。この痛みと引き換えに、より良いデザインが得られます。このような状況を想像してみましょう。親コンポーネントにはいくつかの子コンポーネントがあり、データ自体を取り出して子に渡します。データAPIが変更された場合、親コンポーネントファイルのみを編集して再度動作させることができます。親は、親がそのインタフェースに従う限り変更する必要はありません(eventsとprops)の間にある。より多くのモデリングをもたらす設計、より多くのコードを採用するかどうか、一般に

を(と比較簡単に、私たちは子どもたちがデータ自体を取得するために作られていた)、もっと私たちに考えて、それがするかどうかに依存しますプロジェクトの全ライフタイムを考慮してチームに利益をもたらすしたがって、それらの大規模なシステムは、多くの人々によって、長年にわたって維持される必要があるため、設計のトンを持つことが多い。しかし、それは私の毎日のワークフローで私のためにいくつかのファイルを移動するためのスクリプトのような捨て去りのプロジェクトであれば、何か汚い、なぜまだ作業コードですか?

また、小道具を受け取って自分自身をレンダリングしている子コンポーネントは、pure functionのようなものです。つまり、何度も繰り返し入力すると同じものが出力されます。 functional programmingのように、彼らはしばしばシンプルな形をしていますが、維持管理が簡単ですが、この不純な世界に適応させるために、まず設計し、最初に書く必要があります。

関連する問題