ReduxからMobXへ

なぜ我々はここにいるのか？

遅かれ早かれ、それを モブエックス 他のアプリと同じように。そのため、ざっと見てみることにした。それほど多くの コード についてはすでにご存知だと思う。 リダックス.始めよう。

Reduxとは何か？

で述べたとおりである。 redux.js.orgそれは「予測可能なコンテナの状態」である。 JSアプリ."2015年にダン・アブラモフとアンドリュー・クラークによって作られた。
それは次のように表現できる。 3原則:

1. 単一真実点 - 状態は単一のストアに保持される、
2. ステートは読み取り専用で、ステートを直接変更することはできない、
3. 純粋関数は定義上、与えられたパラメーターに対して常に同じ結果を返し、常に実行でき、副作用がない。

MobXとは？

驚きはない、 モブエックス は状態管理のためのライブラリでもあるが、シンプルでスケーラブルにするために関数型リアクティブ・プログラミング（TFRP）を透過的に適用している。先のライブラリーと同様に、その哲学は3つのポイントで説明される：
1.シンプル - 最小限の、ボイラーフリーのコードで、操作に特別なツールは必要ありません、
2.最適なレンダリング - すべての計算が最適化され、手動でレンダリングする必要がありません、
3.アーキテクチャの自由度 - 実装は自由で、UIフレームワークなしで使用できる。

MobXとReduxの比較

学習

React は、初期設定にまつわる重大な定型文があることで知られている。これを無視することはできません。特に、多くのリデューサーとアクションを持つ大規模なアプリケーションを持っているとき、おそらくあなたはすでにアクションの型を文字列の定数として保持することを決めているでしょう！幸いなことに Reduxツールキット が人気を集めており、現在では次のように書くことが推奨されている。 リダックス ロジック。私に言わせれば、これは気に入っている！それでも、学ぶべきことはたくさんあるが、ツールキットを使ったシンプルな基本セットアップで十分だ。

を見ると MobXドキュメント偶然チョコレート工場に降り立った子供のようだった。例を見ていて、どうやったらうまくいくんだろうとずっと考えていたんだ。でも、リデューサー、アクション、ミドルウェア、その他もろもろを扱うことで、他のことに夢中になりやすくなるのかもしれない。とはいえ、もしあなたがOOPに精通しているのであれば、 モブエックス が自然に身につくだろう。最初のコーディングはかなり少なく、多くのことが舞台裏で行われるため、ほとんどの場合、気にする必要はない。

データ構造 - 状態の内部には何があるのか？

で リダックスプリミティブや配列、あるいは単なる JS オブジェクトをデータとして使用する。
また、配列にデータを格納する場合、パフォーマンス上の理由から正規化するのが一般的です。残念ながら、ReduxのToolkitにあるヘルパー関数（例． createEntityAdapter)は、まだ追加のコードを追加している。

で モブエックスプロパティ、オブジェクト全体、配列、マップ、セットを作成します。 観測可能である。 プリミティブの値については、ここでは触れません。 JS は不変であり、それゆえに異なる扱いを受ける必要がある。そのため、異なる扱いをする必要がある。 可観測 プリミティブを "ボックス "で包み、実際の値のゲッターとセッターは .get() そして .set(newValue) それぞれ observable.box(value)を参照。

インポート { observable, autorun } from "mobx"

const cityName = observable.box("Vienna") // observable("Vienna")と同じ。

オートラン(() => {)
    console.log(cityName.get())
})
// 印刷します：ウィーン

cityName.set("アムステルダム")
// Prints：アムステルダム'

データを正規化する必要はない。 モブエックス 可観測オブジェクトをクローンし、オブザーバブルにし、オブザーバブル・プロパティのいずれかを更新すれば、すべての変更がストアに反映されるようにする。

データの場所 - 店舗

私たちには、真実の唯一の情報源がある。 リダックス.状態を1つの場所に保持することで、データがアプリのあちこちで重複しないようにし、デバッグが容易になる。

モブエックス actually encourages having at least two separate stores, one for the UI state and one or more for the domain state. That separation allows us to reuse the domain in different applications.

というのも、私たちは次のような制約を受けないからだ。 JS プレーンなオブジェクトであれば、著者が提案するように、特定のドメイン・オブジェクトのために独自のクラスを作るのは自然なことのように思える。ここで モブックス オブジェクト指向のプログラミングが好きな人なら、その良さがわかるだろう。メソッドを持つことができ、何が観察可能かそうでないかをコントロールできる。さらに、複数のストアを組み合わせて参照を共有することもできる。

不変と変幻自在

リダックス の更新が必要である。 変異しない を返さなければならない。したがって、既存の配列に新しい項目を追加したい場合は、現在の配列にその項目を追加するだけでなく、新しいインスタンスを返す必要がある。

function todoReducer(state = [], アクション) { // ここでは新しい配列を作成し、スプレッド演算子を使って古い値を保持する。
    // ここでは、新しい配列を作成し、spread演算子を使って古い値を保持する。
    return [
      ...state、
     action.payload
    ]
}

そして モブエックス観測可能なプロパティを変更することができる。 トドス 配列に変異を与えている。元の配列を アド・トド

クラスObservableTodoStore { {.
  todos = []；

  コンストラクタ() {
    makeObservable(this, {
      todos: observable、
      addTodo: アクション、
    });
    autorun(() => console.log(this.todos.length)))。
  }


  addTodo(task) {
    //ここでは、新しい項目を既存の配列にプッシュしているだけです！
    this.todos.push({
      task: task、
      completed: false、
    });
  }

}

observableTodoStore = new ObservableTodoStore()；
observableTodoStore.addTodo("Some tough thing to do")；

さらに、直接 トド リストを見てみよう。 オートラン のobservable配列の変化に気づく）。 トドス).

observableTodoStore.todos.push("Some other tough task")；

// さらに興味深いのは、特定のToDoプロパティを更新するときだけです。
// observableTodoStore.todos[1]を更新するときだけ、MobXは警告を発します。
observableTodoStore.todos[1].task = ("Maybe something more effortless")；

デバッグ

個人的には、クロームがとても気に入っている。 Redux DevToolsエクステンション.アプリの状態をざっと見ることができ、状態の変更ごとに行ったり来たりできる（タイムトラベル！）素晴らしい機能がある。このようなことが可能なのは、前の状態を変更しないという原則があるからだ。

ストアに抽象化されたレイヤーが増えることで、デバッグのプロセスが難しくなる。その MobXクローム拡張機能 しかし、慣れるには時間が必要かもしれない。

しかし、例えば、次のようなものがある。 オートラン を使い始めると、おそらくたくさん使うことになるであろうトラック機能。 モブエックス で、状態がいつ変化するかをチェックしたい。注意しなければならないのは、この関数は観測した変化だけを追跡するということだ。それは、関数が初めて実行された時点で決定されます。 モブエックス は、その最初の呼び出しの間に読み込まれたすべてのobservableを購読し、それらが変更されるたびにトリガーされます。

人気

人気を見ると、ここではリダックスが勝っている。近い 4M ダウンロード npmからの週当たり MobXに45万ドル.また、各ライブラリのGitHubのリポジトリにおけるコントリビューターの数（~870 > 270）と星の数（57k > 24k）を見ると、Reduxが有名ブランドであることがわかる。

その一方で JSの現状2020レポート 両者の満足度はほぼ同じである。 プロジェクト.

このグラフの満足度は、"また利用したい／（また利用したい＋利用したくない）"と表現されている。

結論

このコンテストに勝者はいない...まだね！ちなみに、コンテストは全くありませんでした😉私は、どちらのライブラリも基本的なタスクを達成することで素晴らしい仕事をしていると信じています。 JSアプリケーション .との毎日の仕事を見るには、もう少し時間が必要だ。 モブエックス とは異なる リダックス どのような場合にお勧めできるのか。

今のところ、ReduxのDevToolsの "タイムトラベル "がすでに恋しいと言える。 モブエックス とてもわかりやすく、書かれたコードもずっと読みやすく見える。

とはいえ、どのような形で 可観測 マジックを見るたびに、自分のPCのリソース（CPU時間、メモリ、ドライブなど）がどのくらい使われていて、どのくらい効率的なのか気になる。それが私の次の研究段階になることは間違いない。

願わくば、このような特殊な問題をどのように解決できるかについて、本当にエキサイティングな説明をお返ししたいと思います。 モブエックス.それではまた！