flux/ReduxのStoreの持ち方について思う事 | scratchpad
fluxもReduxもどうデータを持つかについてはあまり多く説明されてない気がします。もちろんアプリケーションによって持ち方は異なるとは思うんですが、自分用のメモとして改めて考え方を整理しておきたいと思います。 Store分割の単位：画面 vs ドメインモデル Storeを画面毎に分割すべきかドメインで分割すべきか否かという議論があると思います。個人的にはドメインモデル毎に分割して整理すべきだと考えています。過去にfluxでフルSPAを一人で開発した時は最初はある程度画面毎にStoreを分割してたんですが、すぐきつくなってきてドメインモデルで分割し直しました。 画面毎に分割すると画面が増える度にStoreを増やすことになります。しかし画面が増える度にドメインの概念やデータの種類が増えるわけではないので、この場合明らかに重複した無駄なコードを書いてる事になると思います。 もちろんアプリケーシ
ドメイン駆動Vuexで複雑さに立ち向かう
スタディスト開発部、フロントエンド担当の小宮山です。走ることが楽しくなりすぎてフルマラソン完走が当面の目標です。 今回は私達が進めているUIリニューアルプロジェクトにおける、フロントエンド設計の心臓部についてご紹介したいと思います。盛り上がりつつあるものの、まだまだ実践的な情報が少ないVue界隈に少しでも貢献できましたら幸いです。 画面駆動Vuexの頃プロジェクト始動当時は私含め大規模プロダクトにVuex（さらにその他Flux状態管理も）を導入して開発を進める経験も知見もほぼない状況でした。 そして開発していく画面デザインの大枠は出揃っている状態だったので、計画も実装も画面単位で区切って進みだしていきます。 こうした状況でVuexのstoreはどのような方針で実装されていくか。正確に表現するなら、特に方針なく実装していくとどうなるか。画面ファーストで、画面から使いやすく、画面ごとに専用なs
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
