Reactの状態管理ライブラリを考える

Posted at 2022-12-07

こちらの記事は金属加工プラットフォームを開発・運用するCatallaxyのCatallaxy Advent Calendar 2022の12/2の記事となります。

前提

既存システムではReactのContextを使用しているのですが、使い方があまりよくわかっていなかったので他のライブラリでの置き換えも含めて検討しようと思って調査をしました。

用途としては

の２つで、どちらもデータとしては小さいものです。
使用するデータをシステムでグローバルに管理するような用途は考えていません。
基本的にはコンポーネント間のデータの受け渡しはPropsを経由するので使用頻度はそれほど多くありません。

既存のコードを読む限り、ReactのContextで一見大丈夫な様に見えました。
なのでReactのContextについて用法・用量の注意点が無いか調べていた所、この記事に行き当たりました。

すると、アンチパターンの１に思いっきり該当していました。
自分が実装したわけでは無いのですがこういう風に実装したい気持ちはめっちゃわかるので、コーディングルールやPRでのチェックで回避しないといけない→それはちょっとなぁとなりました。

というわけで他のライブラリがどうなっているかを調べました。
色々な記事を参考にしましたが、ざっくりな分類としては下記のスライドで把握できました。

また、比較記事として次の記事を参考にしました。

Reduxについては以前別のシステムで使っていたのでなんとなくの印象なのですが、設計・実装が複雑になりがちなので今回の目的には重たいかなと思いました。

Zustandについて紹介記事を読んでみましたが、Reduxとは違ってシンプルに書けそうな印象でした。
React状態管理ライブラリ Zustandを使ってみた - DevelopersIO

shallow、overwrite辺りの挙動がポイントになりそうですね。

Atomのアーキテクチャについては、状態管理する単位が小さくまとめやすいなぁという感想でした。
なので当初はRecoilでよさそうかなぁと思ってました。
懸念材料としては、Atomのキーを管理するコストがかかりそうだなぁというのがありました。

JotaiはRecoilの懸念材料が無くなったので特に問題がなさそうでした。
複雑な使い方をすると機能が足りないとかという問題が出てくるかもしれませんが、現状の要求にマッチしていると思いました。

現状の要求を考えると、最も懸念点が少ないのでJotaiを使ってみようと思います。

Jotaiに限らず状態管理ライブラリを使った場合に問題が出るのは設計部分だと思うので、それはまた別記事にまとめたいと思います。