これは React Advent Calendar 2019 の22日目の記事です。
はじめに
先日、「TwitterやSlackのRedux Storeを覗く」という記事が話題になっていました。そこでも述べられているように、Reduxを用いたアプリケーションではStoreの設計が重要になってきます。筆者も、最近友人とReact(Redux+ReduxSaga)+FirebaseのWebアプリを開発する中で Storeの構成についてや、Redux-Sagaを呼び出すタイミングの整理をしたシーンがありました。その際、PlantUMLのマインドマップを用いたところ、スッキリと情報を整理することができました。この記事では、どういった経緯でマインドマップを利用することになったのか、またどのように活用したのかということを書いていきます。
特定のSagaを呼び出す適切なタイミングを考える必要があった
ReduxとRedux-Sagaを用いて開発を進める中で課題に感じていたことが**「様々にあるSagaはどのタイミングで飛ばすべきなのか、どのタイミングで飛ばさなければいけないのか」**ということです。またそれに関連して「画面をレンダリングする時に必要なstateが存在しないという状況を無くしたい」ということも感じていました。
何がいけなかったのか
上述した課題に直面した原因は**「stateの依存関係およびそのstateを取得するSagaを飛ばすタイミングを考慮していなかったこと」**です。この状況の例えとして、Twitterのようなフォローユーザー一覧画面やタイムライン画面を持つアプリを想定して考えてみます。
上の図の中では、ホーム画面、フォローユーザー一覧画面、タイムライン画面の三つの画面があります。そして、それぞれの画面がそれぞれの画面の描写に必要なstateを持っています。ここでは、フォローユーザー一覧画面をレンダリングするタイミングでSagaを飛ばしてstateC（フォローユーザー情報）をFirestoreに問い合わせています。一方で、タイムライン画面はstateD(タイムライン情報)を持っているのですが、**これはstateC（フォローユーザー情報）に依存しているstateになります。フォローしているユーザーの情報が無ければタイムラインを表示できないからです。**ここにstateの依存関係があるのですが、これを考慮していなかったためフォローユーザー一覧画面を経由してからでないとタイムラインが正常にレンダリングできなかったり、タイムライン画面をレンダリングするタイミングでもう一度フォローユーザー情報を取得するSagaを飛ばさなければいけないという冗長な作りになっていました。
こういった問題が浮き彫りになったため、情報を整理するためPlantUMLのマインドマップを用いて考えてみます。
マインドマップを用いて整理する
前述した状況をマインドマップを用いて表現したのが以下の図です。
先ほどの流れで、まずは画面ベースでstateを考えてみます。このマインドマップでは各画面が持つstateを末端に表しています。ここで、Sagaについて考える上での観点が二つあります。一つ目は、state Aがホーム画面とフォローユーザー一覧画面で重複していること、二つ目はタイムライン画面においてstate D(タイムライン情報)がstate C(フォローユーザ情報)に依存していることです。
まずは一つ目について考えます。state Aに関して、それぞれの画面をレンダリングする時に別々のSagaによって取得することは冗長です。なので、state Aを取得するSagaは1回だけにして、認証後の初期外部リクエスト(initial saga)によって該当データを取得することにします。
次に二つ目についてです。state D(タイムライン情報)はstate C(フォローユーザ情報)に依存しています。つまり、state Cが無ければstate Dも表示させることができません。そこで、プロフィール画面もしくはタイムライン画面個別に紐づいたSagaではなく、一つのSagaとしてstate Cを取得することにします。こちらも認証後の初期外部リクエスト(initial saga)で飛ばすのが良さそうです。
ここまでPlantUMLのマインドマップを用いてstateとSagaについて考えてみました。ここで、stateとSagaについてまとめてみます。下図のように、二つの画面で重複していたstate Aと、依存関係にあったstate Cはまとめて認証後の初期外部リクエスト(initial saga)によってデータを取得するようにしました。
また、Storeに関しては下図のような構成になっています。最初は画面ベースでstateを考えていましたが、state Aが複数の画面で重複しているため冗長な構成を避けたいこと、開発規模が小さいことから最終的には画面ベースではなくドメインベースの構成になっています。これらに加えて、開発中のアプリのビューは完全に決定してるわけではないので、後々のビューの変更にも強いドメインベースを採用しています。画面ごとに分担作業するなどの場合は冗長でも画面ベースで考えるというのはありかもしれません。ちなみに、Redux公式ドキュメントはドメインベースでのStore設計を推奨しています。また、Store設計に関しては「TwitterやSlackのRedux Storeを覗く」の記事が勉強になりました。
おわりに
今回、マインドマップを用いてSagaの呼び出し順序やStoreの構成を考えてみました。ReduxやRedux-Sagaを使用し複雑なビジネスロジックになる場合、整理のためにマインドマップを用いてみてはどうでしょうか。また、Storeの設計を考える上で「TwitterやSlackのRedux Storeを覗く」の記事はとても参考になると思いました。