次のReact状態管理 MobXのStore考察 - Qiita
先日の投稿に続き第2弾です。MobXではReduxと違い、複数のStoreが存在し、複数のProviderを保持出来ます。ReduxにもProviderがありますが、それはコンポーネントルートに一つあるのみで、初期設計が終われば普段意識することはありません。 MobXでは、Storeをどこで生成し、どうProviderに与えるのが良い設計なのか。この観点に踏み込んだ記事を発見できていないため、独自方針ですが綴ることにしました。（優しいマサカリをお待ちしてます） Redux踏襲パターン Redux実装経験者も、そうでない方も、これが一番わかり易いかと思います。「Providerを一つしかもたない」です。こうしてしまえば、全てのコンポーネントが全ての状態にアクセス出来る状態になりますし、Reduxの1Storeと並列で考えることが出来ます。シンプルさを求めるなら、これで十分でしょう。 impo
次のReact状態管理はMobXにする理由 - Qiita
2017/12/29更新： ReduxとMobXの選定観点 も併せて見ていただければ幸いです front-end-handbook-2017 に名前が挙がっていた MobX に興味が湧き調べてみました。その結果、掲題のとおりの記事を書きたくなるまでに至ったので、個人的にReduxより優れていると感じた点を挙げたいと思います。 記述量が圧倒的に減る Store概念のわかり易さ バケツリレーが実質不要になる injectを活用するとjsxが純粋になる デコレーター層の存在 記述量が圧倒的に減る 一つの双方向な値をコンポーネントに表示するために、Reduxでは以下の作業が必要でした。 Reducer に initialState として値を追加 Reducer で Object.assign した新しい State を生成 ActionType を追加 ActionCreator を追加 Act
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
React Redux テスト考察 - Qiita
