いまさらですが、俺的Real world MobXです。 いちおう半年くらい仕事でも趣味でも触ってきてての今です。 あくまで1つの例ですが、どこかの誰かの何かの参考になれば。 その前に こんな風に使ってますを紹介する前に、もやもやーっと思ってることを箇条書きにしておきます。 俺が考えた最強のアーキテクチャ そんなものはない 声のでかいやつの言うことを真に受けるな 納得できない部分があるなら採用するな Reduxとの比較 Reduxでできたクソコードがあるように、MobXでできたクソコードもありえる 役割が薄い分、そのリスクはMobXの方が高い（設計力が試される）と思ってる コードの記述量は絶対に減るので、書き味は良くなる 書きやすさと無秩序は紙一重 Flux的なアーキテクチャを踏襲するべきか Action的なものを投げる必要はないが、投げてもいい Storeも単一でもいいし、複数にしてもい
Kea is the name of the latest state management library for React that you have never heard of. It’s also the name of the smartest parrot in the world. Much like kea the parrot, kea the library doesn’t invent anything new. Instead it manipulates existing tools to get results in the shortest time possible. Kea the library is an abstraction over Redux, Redux-Saga and Reselect. It provides a framework
難点は、Store が増えるほどトランザクションが追い辛くなることです。リファクタ・スケールにおいては、簡単な部類ではないと思います。普段から出来ることといえば、他の Store が別の Store の状態を直接参照しないようにすることぐらいです。 MobXにする境界 1.異なるプラットフォームでドメインモデルを共有したい React + MobX と紹介されることが多々ありますが、両者は疎結合で MobX をドメインモデルとすることが可能です。別の view で再利用可能で、データバインディングフレームワークと比べ、ドメインモデルが切り離されています。 そのため react-dom・ReactNative でドメインモデルを共有することもなども容易です。もしこの点に魅力がなければ、Reactに固執する必要もないかもしれません。 2.Storeの密結合が起こりえない json を取ってきて
I used Redux excessively the last years, but spent the recent time with MobX as state management alternative. It seems that Redux alternatives evolve naturally into confusion in the community. People are uncertain which solution to pick. The issue isn't necessarily Redux vs MobX. Whenever there exists an alternative, people are curious what's the best way to solve their problem. I am writing these
For Spectacle Editor, our current collaboration with Plot.ly, we decided to use MobX to handle application state instead of Redux. Redux is an amazing framework, and here at Formidable we continue to use it on new and existing client projects with great results. In part, the decision to use MobX was driven by a desire to test a new approach to React app state, learn new patterns, and challenge our
2017/12/29更新： ReduxとMobXの選定観点 も併せて見ていただければ幸いです front-end-handbook-2017 に名前が挙がっていた MobX に興味が湧き調べてみました。その結果、掲題のとおりの記事を書きたくなるまでに至ったので、個人的にReduxより優れていると感じた点を挙げたいと思います。 記述量が圧倒的に減る Store概念のわかり易さ バケツリレーが実質不要になる injectを活用するとjsxが純粋になる デコレーター層の存在 記述量が圧倒的に減る 一つの双方向な値をコンポーネントに表示するために、Reduxでは以下の作業が必要でした。 Reducer に initialState として値を追加 Reducer で Object.assign した新しい State を生成 ActionType を追加 ActionCreator を追加 Act
先日の投稿に続き第2弾です。MobXではReduxと違い、複数のStoreが存在し、複数のProviderを保持出来ます。ReduxにもProviderがありますが、それはコンポーネントルートに一つあるのみで、初期設計が終われば普段意識することはありません。 MobXでは、Storeをどこで生成し、どうProviderに与えるのが良い設計なのか。この観点に踏み込んだ記事を発見できていないため、独自方針ですが綴ることにしました。（優しいマサカリをお待ちしてます） Redux踏襲パターン Redux実装経験者も、そうでない方も、これが一番わかり易いかと思います。「Providerを一つしかもたない」です。こうしてしまえば、全てのコンポーネントが全ての状態にアクセス出来る状態になりますし、Reduxの1Storeと並列で考えることが出来ます。シンプルさを求めるなら、これで十分でしょう。 impo
For a lot of JavaScript developers, the biggest complaint with Redux is the amount of boilerplate code needed to implement features. A better alternative is MobX which provides similar functionality but with lesser code to write. For MobX newbies, take a quick look at this introduction written by MobX’s creator. You can also work through this tutorial to gain some practical experience. The goal of
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
