コンポーネント指向のUI開発時に起きがちな密結合・複雑化問題をStoreパターンで解決する

Vue.jsを用いたコンポーネント指向のフロントエンド開発において弊社が導入したStoreパターンについてご紹介します。

[chrome_cgi]

これ、自分も業務でVueアプリ作ってるけど、一旦 Vuex(Flux) でやってみたら規模に比して必要以上に複雑になりがちで、単純な shared state 使う形に戻した経験があるので納得感ある / そうですね複雑というより「冗長」ですね

[yojik]

StoreがModelでVueインスタンスがViewModelでテンプレートがViewというMVVMそのものなんだけど、これで十分だと思う。

[kat21]

GoFのMediatorとは違うのかな？

[bc_rikko]

Flux(Vuex)よりも、シンプルかつ柔軟に開発するためのStoreパターン

[h_taiji]

これは、遥か昔にMVCと呼ばれていたものではないか、、、、と邪推した

[hiroomi]

”Storeというグローバルな共有オブジェクトに複数のコンポーネントから使用される共通の状態・処理・イベントを管理させることで、コンポーネント同士を分離する考え方”

[khtokage]

公式に載ってる通りだけど、バケツリレーがツラくなってきたらまずはStore(EventEmitterを使ったり使わなかったり)、複雑になってきたらFlux、という使い分け方がよいっぽい。

[pmint]

これって「Vue.jsは投げ捨てろ。テンプレートさえありゃいいんだよ！」ということ？

[efcl]

Store/Stateなパターン

[north_korea]

これReduxと同じじゃね？

[marisatokinoko]

fluxで複雑度が上がるとは思わないなぁ、ただ宣言的な書き方が強制されるんでそれがだるく感じることが多々あるという気がする

[field_combat]

これいいな

[assaulter]

Vue.jsってバケツリレーじゃないのか（触ったこと無い

[Tomato-360]

]

[otoan52]

Vue.jsを実際の製品開発に使った事例での、ベストプラクティス的な話