ReduxのStore設計で気をつけたこと

f:id:yamamoto5555:20200821112754j:plain

Web開発チームのフロントを担当している山本です。

今年リリースをした集計機能でReduxを導入しました。集計機能とは、お客様によりWowTalkを使っていただくために、社内の浸透をサポートする機能です（詳しくはこちら）。Redux導入にあたり一番頭を悩ませたのが、Store設計でした。初めての設計ということもあり、いろいろと試行錯誤したので、今回はReduxのStore設計について紹介します。

公式のReduxのStore設計
他のプロジェクトのStoreは？
集計機能のStore構成
まとめ
- 参考URL:

公式のReduxのStore設計

Reduxのドキュメントでも、複数のデータを取り扱う時の3つのポイントが書かれています。

Domain data: アプリケーションが表示、使用、または変更する必要のあるデータ

　　例）サーバーから取得するデータ

App state: アプリケーション独自の動作データ

　　例）データの選択状態やリクエスト中の状態

UI state: 現在のUIの表示方法を表すデータ

　　例）モーダルが表示か非表示か

この3つの分け方は、データを取り扱う時に、明確な指針としてとても助かりました。基本的には上記のことを元に、今回の集計機能のStoreも構成しています。

他のプロジェクトのStoreは？

具体的な例も参考にしたかったので、react-redux-realworld-example-appというプロジェクトを見つけました。このプロジェクトでは、Twitterのように自分で簡単なメッセージを投稿できるようになっています。reducersを見てみると、editorやProfileといったパーツごとにreducerを分けており、フラットに整理されていました(プロジェクトの大きさによるかもしれませんが)。またcommon.jsでは、ユーザー情報など共通で管理を行っているデータをまとめています。

正直、いろいろな具体的例を参考にしたかったのですが、その当時はなかなか見つからず。。。（私の探し方が悪かったのかな）。今は、 React Developer ToolsでStoreの中を覗けることを知ったのですが、早く知りたかったです！React Developer Toolsの使い方なども書いてあり、こちらの記事がとても参考になりました。私もこれからいろいろなStoreの中を覗いてみたいと思います。

集計機能のStore構成

今回の集計機能では、ページごとに表示するデータが異なるので、パーツではなくページごとにStoreを構成しました。それは、今後のことを踏まえても、ページ数をかなり増やすことは考えていなかったこともあり、ページごとにStoreを作ることに踏み切ることが出来ました。

-cache
    |_common
-page
    |_common
    |_activeUser
    |_lastActive
-ui
    |_common
    |_activeUser
    |_lastActive

上記が考えたStore構成です。基本はドキュメントにあった3つのポイントから構成し、さらにページごとに分けています。ページ関係なく共通で使うものはcommonに入れて管理しています。今のところ、実装する中ではどこでデータを管理しているのかが見つけやすいです。

まとめ

今回はStoreの設計をしたのですが、どれが正解かは分からない部分が多かったです。集計機能では、ページごとに分けて良かったとは思っていますが、サービスによっては、やはりパーツごとに分けたほうがいいものもあり、一概にはどれがいいとは言えないと思いました。また、これからさらに集計機能を進化させたいので、その中で新たな壁にぶつかりそうな気がしています（既に壁にぶつかったので、その内また違う記事で書きます）。まだまだRedux初心者なので、積極的に他のサービスからも学んで行きたいです！