MobXを使ったアーキテクチャについて

- main.js
- store
  - object
- event.js
- app.jsx
- container
- component

main.js

いわずもがなエントリーポイントです。

mobx.useStrict(true);

const store = new Store(initialState);
const event = new Event(store);

ReactDOM.render(
  <Provider event={event}>
    <App store={store} />
  </Provider>,
  document.getElementById('root')
);

それぞれ、

• Store: アプリの状態でありMobXのObservableな値たち
• Event: アプリで起こる操作（によりStoreを更新するハンドラ）
• View: ReactのViewであり、MobXのObserverに

この3つでだいたい事足りると思います。
`mobx.useStrict(true)`は、Storeで扱うObservableを更新できる箇所を縛るものだと思ってください。
それができるのがEventで、他からはStoreの状態を更新できない、のでそのままViewに渡してます。

`mobx-react`の`Provider`でEventはContext経由で渡すようにするのが最近は好きです。
見た目を構成するために必要なStoreのバケツリレーはある程度まで許容できても、ハンドラはな・・という好みなので人それぞれな気がする。

Store w/ Object

• 単一Storeである必要はないので、それぞれの債務に応じた状態をそれぞれの場所に配置できる
• でもStoreAとStoreBの複合状態を、Viewで作るのはちょっと・・となる
• なら、個別のStoreは子Store（＝Object）として、それらをまとめる親Storeに持たせればいいのでは

という感じです。

class Store {
  constructor(initialState) {
    this.ui = new UiObject();
    this.foo = new FooObject();
    this.bar = new BarObject();

    extendObservable(this, {
      isFooAndBar: computed(() => {
        return this.foo.isFoo && this.bar.isBar;
      })
    }, initialState);
  }
}

複数のStoreを持つといえばそうだが、単一であるとも言える・・のは、こういうわけでした。

class Object {
  constructor() {
    extendObservable(this, {
      // ここにstateを定義してく
      selected: null,
      foo: 'foo',
      bar: [],

      hasBar: computed(() => { return this.bar.length !== 0; }),
    });
  }

  setSelected(target) {
    this.selected = target;
  }
}

Store / Objectを作るときに心がけてるのは、いわゆるGetterメソッドを"生やさない"こと。
というのも、それは9割がた`computed`で表現できるはずだから。そうしないならMobX使ってる意味ない。

もうひとつは、Observableである必要のないデータは、`extendObservable()`の外に出すこと。紛らわしいから。
必要に応じて`.shallow`のModifiersを。

あと冒頭で`useStrict(true)`したので、Store / Objectの値を更新するには、`mobx.action`でラップした関数の中でやらないとダメです。

デコレータが使える案件なら、

class FooObject {
  @observable foo = 300;

  @action
  setFoo(foo) { this.foo = foo; }

  @action.bound
  setFoo2(foo) { this.foo = foo * 2; }  
}

てな感じに`action`化できる + `bind(this)`も手軽にできて最高なんですが、そうではない場合、愚直にラップしていくしかないです・・・。

Event

最後の方がこちら。
StoreおよびObjectを変更できる唯一無二の存在。

Viewは表示だけ、Storeは状態だけ、なのでそれ以外はすべてココでやるようにしてます。

class Event {
  constructor(store) {
    this.store = store;
  }

  onClickFooBtn(value) {
    this.store.foo.setFoo(value);
  }

  onChangeBar(id) {
    fetch(`/api/bar/${id}`)
      .then(res => { this.store.bar.updateBar(res.json()); })
      .catch(err => { this.store.showError(err); });
  }
}

全てのStore/Objectのためにこの層が必要か？と言われると微妙だと思いますが、ココに全て寄せる意義はあると思うので、それも好き好きかなーと。
ViewからStoreを直で叩こうとすると、UI絡みの処理やら非同期の処理やらどうすんの・・？ってなりがちなので、こういう層はあってもいいと思う。

この構成だと、`mobx.reaction()`とかもあわせ技的に使えるのでそこは強いと思います。

reaction(
  () => this.store.bar.isBar,
  (changedBar) => {
    fetch(`/api/bar/update`);
    this.store.ui.changeBar();
  }
)

ユーザー入力を起点にして全てのハンドラを手続き的に書いていくのではなく、ユーザー入力によって状態が更新される、それに呼応して勝手に処理されるというイメージで。
これがキマるとMobX最高ってなると思います。

Container / component

これはReactの話なのでサクッと。

• Container: `context`からEventを受け取る、各Storeも直接受け取る
• Component: Containerにぶら下がる、`props`で全部もらう

いわゆるプレゼンテーショナルなコンポーネントか、そうでないか。
Containerも出来る限り増やしたくないので薄いツリーを心がけたい気持ちはある・・が。
Storeを受け取るときにそのまま受け取るか、View用のマッピングを通して渡すかとかも好き好きかなーと。

MobXでやる場合に必要なのは、`observer()`でラップすることだけです。

autorun(() => {
  () => this.store.ui.route,
  (route) => location.hash = `!/${route}`;
});

悩んだらVueを

他のフレームワークとの比較 - Vue.js

ここにも引用されてる通り、React x MobXはVue.jsと似たような感覚で使えます。
ということは、Vuexとかの段階的なアーキテクチャ設計が真似できるということで・・・！

• Storeを直叩きするもよし
• Mutationを作るもよし
• GetterとActionを分けるもよし

迷ったら参考にしてみるとよいと思います。

Observableな値にも種類がある

一口に`observable(value)`といっても、実は種類があります。

const obj = { a: { b: { c: 1 } } };

// same
observable(obj)
observable.object(obj)
observable.deep(obj)

// modifier
observable.shallow(obj)

`observable()`で基本的になんでもObservableにできますが、それぞれのターゲットを指定する記法もあります。
`.shallow`とか`.deep`とか`.ref`とか、Modifiersってのもあります。（`computed`も`action`も実はModifiers）

Observableな値のタイプを指定するのがModifiersで、まあ知らなくても困らんのでは？って感じ。

mobx/api.md at gh-pages · mobxjs/mobx · GitHub

APIを全部は使わない

The most important MobX api's. Understanding observable, computed, reactions and actions is enough to master MobX and use it in your applications!

と、ドキュメントにもあるように、いろいろAPIはあるけどほとんど使わないで済むはずです。

ライブラリは必要に迫れれてはじめて入れるもんです。
https://github.com/mobxjs/mobx-utils っていうUtil集もあるので、必要になったときに探してみると吉です。

What does MobX react to?

必読です。

Understanding what MobX reacts to | MobX

`autorun`とか`observer`とか、Observableな値の更新に呼応する系の動きを把握するのがMobXを使いこなすポイントで、その仕組が書いてあります。

// コレと
<App>
  <Foo bar={foo.bar} />
</App>

// コレは挙動が違う
<App>
  <Foo foo={foo} />
</App>

`foo.bar`が更新された場合、前者は`App`が`render()`されるのに対し、後者は`Foo`が`render()`されます。
なんとなくわかるかな・・？
つまり、該当するプロパティにアクセスした関数が、トラッキングされて自動で呼ばれます。

なのでパフォーマンスにすごくこだわるならば、これを熟知した上で`props`を渡さないとダメです。
ただコンポーネントに渡す`props`はきっちり限定したいと普通は思うと思うので、まあ差し迫ってからでいいかと。