Kindleの「React + Redux入門 - ReactはできるけどReduxがわからないやってみたい人のためのreact-redux入門」が、読み放題(Kindle Unlimited)に入っていたので読んでみました。
私は、ReactもReact Nativeも使っているのですが、今までは小規模なアプリケーションがメインだったので、Reduxを実務で使うことはありませんでした。あるプロジェクトではMobXを採用しまして、MobXは簡単に習得できる点が気に入っています。
次回はReduxによる開発を視野に入れたいと考えているので、改めて試してみた次第です。いざ本気で試してみたら、Reduxのメリットとデメリットが見えてきました。
本書で得た内容を整理しつつ、考察していきたいと思います。
目次
Reduxのメリット
状態を集約できるので、混乱しにくい
Reduxを採用しない素のReactの場合、データは親コンポーネントから子コンポーネントへ、propsを経由して渡される事になります。最初の内はそれでも良いのですが、3つ4つ... と増えていくと、どんどん煩雑になっていきます。
一方、Reduxを使うと、データを全てストア(Store)に集約する事ができます。これにより、バケツリレーのようなデータの伝搬が不要になるのです。
データの更新に制約が生まれるので、品質を下げにくい
リデューサー(Reducer)の関数を叩き、データの更新を依頼するためには、必ずアクション(Action)の定義が必要になります。つまり、正規のプロセスを踏まないとStoreにあるデータを変更することができないのです。
それに、データの変更がReducerに集約されるので、データの更新を追跡(トレース)しやすくなります。
Reduxの考え方自体はシンプルである
MySQLやPostgreSQLをはじめとするデータベースは、SQLを発行しないとデータを更新することができません。私は、Reduxはそれと似ている考え方だと解釈しました。
SQLの発行が、Actionの発行に置き換わっただけです。さらに言うと、Web+DBのシステムでは、状態がDBに集約されています。Reduxでは、DBがStoreに置き換わっただけであるとも言えるのです。
Reduxの考え方自体はシンプルであり、Web系エンジニアの方であれば、以下のように置き換えてみると理解が早くなるのではないでしょうか？
- Action => SQL
- Store => データベース
- Reducer => SQL関数、または更新ロジック
Reduxのデメリット
正規の手続きをショートカットしたくなる時がある
Reduxが小規模アプリには仰々しいと思われている理由は、考え方にあるのではなく、データを更新するまでのプロセスにあるのではないかと思います。
- Reducerを定義
- Actionを定義
- React ComponentとReduxを接続(connect)して、Storeを参照したりdispatchできるようにする
- コンポーネント側でdispatchして、Reducerにデータの更新を依頼する
小規模アプリであれば、わざわざ段階を踏まなくても、データの変更はライトに関数一つで十分だと、思ってしまうこともあるかと思います。もしくは、自前でSingletonを定義するという手段も、無くはありません。
コード量は増える
単純なコード量は、やっぱり増えます。
- Actionのtypeはハードコードしたくないので、定数で管理したい。
- Actionは、Actionを生成する関数を経由して発行させたい。
- Reducerで、typeによる書き分けが必要である。
- ...etc
ただ、コード量こそ増えるものの、責務はきっちり分離されています。そのため、アプリケーションの複雑度は反対に下がりそうです。
Middlewareを組み合わせると覚えることが増える
ReduxにMiddlewareを組み合わせると、構成が複雑になり、覚えることが増えます。あと、使うライブラリが増えるほど、サービスリリース後のメンテナンスが大変になっていきます。
安易にMiddlewareの導入は決めずに、よく検証してから決定したほうが良いです。
Reduxを採用するかどうかの判断基準
読んでいて、やっぱりSPA(Single Page Application)であれば、Reduxを採用する価値は高そうだと感じました。
一方で、SPAではない、あくまでReactをViewライブラリとして使うようなプロジェクトでは、Reduxを無理に入れる必要はなさそうだとも思います。
以下のような順番で検討するイメージです。ただ、規模の拡大が予想されるようなアプリケーションであれば、最初からReduxを採用する選択肢も視野に入りそうです。
- Reactのstateで状態を管理する
- MobXで状態を管理する
- Reduxで状態を管理する
さいごに
Reduxは、複雑だと思われやすい側面があります。でも、改めてしっかり理解してみたら、考え方は単純であることに気づきました。
小規模アプリではデメリットのほうが目立ちますが、アプリケーションの規模が大きくなるほど、コンポーネント間のデータのやり取りは煩雑になってきます。Reactを使っている方であれば、使うか使わないかはともかくとせよ、知っておいて損はないのではないでしょうか？
補足：Reduxは、Reactに限定されているわけではない
Reduxは、Reactに限定されているわけではなく、あくまで単なるアーキテクチャです。
ちなみに、Vue.jsですとVuexというライブラリがあります。状態管理というコンセプトは同じですが、「ゲッター、ミューテーション、モジュール・・・」と、コアとなる要素の名前だけでも全然違いますのでご注意ください。
