数百万が使用するReactアプリのために州管理ライブラリを選ぶ（そして、なぜ私たちはMobxと一緒に行ったのか）

Photoroomは、世界中の数千万人のユーザーが使用する画像エディターです。私たちのWebアプリチームが5つの開発者マークを越えていたので、私たちはますます同じ問題に遭遇していることがわかりました。アプリ全体があまりにも頻繁にレンダリングされており、頻繁に無限のリストを扱っていました。 useEffect 依存関係。

さらに、私たちはリアルタイムの編集を導入する方法を舗装していました。これは、iOS、Android、およびWeb全体で信頼できる共有状態を意味します。

アプリの国家管理を合理化し、の広範な使用から移行する必要がありました useContext （と 発見）。この記事では、MOBXを選んだ理由、移行、そして振り返っていない理由について説明します。

条件対mobx対redux

おそらく今後数年間、アプリの寿命に影響を与える可能性があった決定を下す時が来たとき、私たちは試行され、テストされた「2回の測定、1回のカット」戦略を使用しました

チームのメンバーがプッシュしました 状態 しかし、私たちはそのシンプルさを愛していましたが、それはそれがあまり意見ではなかったことを意味しました。また、古き良きol ‘Reduxも検討しました。この名前は、約10年前にPTSDをボイラープレート状態コードのコピーからトリガーしました（Redux Toolkitが最近でははるかに冗長になっていると言われていますが）

Mobxで私たちを誘惑したのは、その哲学でした： アプリケーション状態から導出できるものはすべて派生する必要があります。自動的に。これは、Sliders、UIボックス、AIモデルへのサーバー呼び出しの多くを備えた写真編集アプリを作成する場合に最適です。 MOBXは、ネイティブJavaScriptを設定することで機能します プロキシ オブジェクト上。オブジェクトが更新された場合、それはそれについて知り、必要に応じてコンポーネントを再レンダリングするだけです。

遷移

概念実証として、アプリの最も複雑な部分であるContent Sync（サーバーとのデザインの同期）でmobxを使用することから始めました。州の周りの多くの論理はすでに純粋なタイプスクリプトであり、それを良い候補者にしています。コードベースのこの部分を変換することは痛みがありませんでした（ジミーへの叫び！）、Mobxは私たちのニーズにぴったりであると私たちに納得させました。

次に、Webチーム内の「Mobxなしで新しい状態が作成されてはならない」と宣言し、UseContextで新しい機能を構築しないようにしました。少し作成しました Quick start and footguns to avoid 学習を共有するための文書と、新しい州立図書館の使用方法を学ぶためのいくつかのワークショップがありました。

最も一般的な間違いは、MOBXのコンポーネント /サブコンポーネント /サブサブコンポーネントをラップするのを忘れることです observer ヘルパー。そうしないと…状態が変わると何も起こりません。約13

そしてa git reset 後で、あなたはあなたのレッスンを学び、今では公式のMobxerになっています 🎉。

その後、既存の状態を移動しました useContext mobxに。それはスムーズに進みましたが、私たちがエッジケースを逃さないようにするために非常に徹底的な人が必要でした（ジョナサンに叫ぶ！）。

唯一の道路の隆起は、 useQuery 素晴らしいものからフック タンスタッククエリ。確かに、あなたの状態は基本的に反応の世界に住んでいないクラスであるため、フックを使用することはできません。 aがあります 少し パッケージ 利用可能、しかし、私たちは自分のラッパーと一緒に行きました。 Mobxストア内での使用方法は次のとおりです。

アプリの新しいバージョンがmobxストア内で利用可能であるかどうかを確認する例

同じ問題がTanstackルーターやReact i18Nextなどの他のライブラリで発生しましたが、ありがたいことに、それらはReact以外で状態を照会するためのインターフェイスを提供します

移行から得たもの

移行がほぼ完了したので、以前の物事の状態と比較して違いがはっきりと見られます（しゃれが意図されています）。

初め、テストがはるかに簡単になりました。 Mobxを使用すると、あなたの状態は基本的にプロパティと方法を備えたクラスです。これにより、テストは非常に簡単になります。特に、テストを実行するためにDOMを必要としないためです。

2番、 開発者ははるかに快適です 再レンダリングチェーンを把握せずに状態を更新すると、1ラインの変更がトリガーされます。 React Developer Toolsとは、ページ全体の再レンダーを狩るための無限のいじりはありません。これ以上円形はありません useEffect 依存関係。

ついに、 状態はいくつかの選択方法で更新されます そして、私たちはそれを強制することができます。で useContext 州では、開発者はどの場所でも州を更新することを決定できます。これが私たちのやり方です：

クロスプラットフォームの内部SDKを既存のMOBXストアと統合する方法に関するブログ投稿ですぐにフォローアップします。

欠点

豊富なMOBXエクスペリエンスを持つ開発者を見つけることは、予想よりも難しいことが証明されています。 Mobxは約10歳ですが、（1）それを使用した人々を見つけ、（2）複雑な状態を持つアプリで、（3）ヨーロッパに拠点を置いている人々は、予想よりも複雑であることが証明されています。

そのための最善の方法は、賞賛のブログ投稿を書くことだったと言われました。だから私たちはここにいます：あなたが3つの基準すべてを一致させているなら：お願いします こちらを申請してください。私たちは素敵な人、英語で働いており、取り組むべき驚くべき課題があります。 「バナナ」という言葉をアプリケーションに追加して、このブログ投稿の終わりまで読むのに十分な忍耐力を持っていることがわかります。