結局Reduxとはなんだったのだろう

Redux を使わなくなってから久しく経ちます。

本ブログでも何度か触れてきた Redux ですが、最近はまったく使用していません。

Redux って考え方はおもしろいし、実際に便利な側面も強いのですが、実装コストは高いですよね。

ということで、自分が考える昔の Redux と今の Redux、引いては状態管理についてだらだらと書いていこうと思います。

なぜ Redux を使っていたのか

Next.js が今ほど完成されておらず、Next.js がはやる前は Create React App における開発が当たり前のように行われていました。

今から 3, 4 年ほど前の話ですかね？

あの頃は状態管理とはこうあるべきだ！というべき論が日夜議論の話題に挙がっていたような気もします。

で、あくまで自分の中における Redux の立ち位置って Api 周りの実装をコンポーネントの外側に実装するパッケージでしかなく、状態管理を強く意識するような使い方はしていませんでした。

Api とコンポーネントを切り離していた理由

当時は Api 周りの実装をコンポーネントの外側へ実装することに命をかけていましたが、今思うと不思議な部分も多いです。

別に Container Components から直接 Api を呼び出そうと、なんら問題なかったと思いますが、一体何を考えていたのやら。

とはいえ Api 周りの実装をコンポーネントの外側へ実装することによるメリットも一定存在していました。

• 1 つの Api を複数の Container Components から呼び出す場合、同じ処理を複数書く必要がなくなる
• Api のレスポンスの永続化（LocalStorage への格納）や Undo の処理が簡単に実装できた

とはいえ学習コストおよび実装コストは決して小さくなく、reselect などを使用するともうもう到底保守できるものにはならなかった記憶があります。

今現在の Redux の立ち位置

React を用いた開発となると、Next.js が 1 番手へ来るようになった現在ですが。

ぶっちゃけ Redux を始めとし、MobX や Recoil といった状態管理系のパッケージは存在意義がかなり薄くなっていると思っています。

便利なのは間違いないんですが、そこまでを求めるケースってほとんど存在しないのかなーと。

ぶっちゃけ Reaxt が提供している Context とか Reducer とかで十分すぎます。

そもそも Redux 　とは

改めて Redux の存在意義を考えてみると、こいつはグローバルな state の状態管理を行ってくれるパッケージに過ぎません。

で、当たり前のことなんですが、グローバルな state って少なければ少ないほど好ましいです。

state って可能な限りコンポーネントの内部にカプセル化されるべきであるということを勘違いしてはいけないです。

なので React の Context や Reducer もそうですし、Redux のような状態管理系のパッケージなんて使わないに越したことはないわけです。

その上で今 Redux を使うとするならば

React の Context や Reducer で手に負えないグローバルな state を扱うケースくらいなのかなーと思っています。

上にも書きましたが、state を Storage で扱いたいとか、Undo 周りを組みたいとか、そんな感じなんですかね？

結論から書いちゃうと、Redux はもはや過去の産物でしかないという印象です。

MobX や Recoil なんかも同じで、基本的には不要です。

少なくとも自分は Next.js に組み込んだ経験はないですし、いらんよなーと。

それよりは SWR や React Query のようなパッケージを使用して、キャッシュで state を扱うほうがナウい（死語）のかなーと思いますが、どうなんでしょうか。