タスクグループを取得して利用できるようにする

[kuniyuki-f]

完了の定義

• [x] タスクグループを取得するための API エンドポイントへのリクエスト処理が実装されていること
• [x] タスクアイテムコンポーネントからタスクグループの情報が利用できるようになっていること
• [x] サイドバーコンポーネントからタスクグループの情報が利用できるようになっていること

補足情報

• タスクアイテムコンポーネント・サイドバーコンポーネントは実装済み

[kuniyuki-f]

@keitakn

お疲れ様です！

• サイドバーコンポーネントからタスクグループの情報が利用できるようになっていること

ここの実装方針について少し悩んだので相談させていただいてもよろしいでしょうか？ 具体的には、「components/SideBarにどのように TaskGroup を渡すか？」で悩んでいます。

悩んだ経緯

114 で実装したように、現在 TaskGroupはgetServerSidePropsの中で取得しています。

export const getServerSideProps: GetServerSideProps = async (context) => {
  const session = await getSession(context);

  ...

  const fetchTaskGroupsDto = { appToken: session.appToken };
  const taskGroups = await fetchTaskGroups(fetchTaskGroupsDto);

  return {
    props: { tasksRecording, pendingTasks, taskGroups },
  };
};

今の実装だと、templates/TimerTemplateで Props として受け取ったTaskGroupをcomponents/layouts/DefaultLayoutに渡し、そこから更にcomponents/SideBarに受け渡す必要があります。 いわゆる prop のバケツリレー状態になっているような気がします（ここであまり良くない例として紹介されていました💦）

とはいえ、サイドバーで表示するタスクグループは状態変化しないはずなので、getServerSidePropsで受け取った値をそのまま受け渡していって表示するでも良い（ = Context API を使うほどのケースではない）のかな、と考えています。 （実際、components/TaskItemにも同じような対応をしていますし・・・！）

ただ、 #101 みたいに API Routes にリクエスト処理を挟んで、クライアントからTaskGroupを取得するような実装も考えられます。

自分の結論としては、「getServerSidePropsで受け取った値をそのまま受け渡していって表示する」方針で良いと考えていますが、この点についてkeitaknさんのご意見をお聞きしたいです👀

他のタスクも進めていくので、こちらのコメントはお手隙でご確認いただければと思います！ どうぞよろしくお願いします🙇

[keitakn]

@c501306014 色々と進めて頂きありがとうございます🙏

自分の結論としては、「getServerSidePropsで受け取った値をそのまま受け渡していって表示する」方針で良いと考えていますが

自分も結論これで良いと思っています👍

確かにバケツリレーは良くないですが、極端に深くならないのであればある程度許容して良いかなと思います！

ここからは余談ですが、この記事 ではバケツリレーの回避策として useContext を解決策として上げていますが、自分的には Context はちゃんと使わないと無駄な再レンダリングが発生したりと結構難しいので本当に必要になるまで導入は避けたいのと、もし導入するにしてもそのあたりの問題が考慮されている Joutai とか valtio を使ったほうが良いかなと思います！

もっと言うとこれらのライブラリを入れるのも最終手段で以下の記事のようにPropsで ReactNode 自体を受け取ったり、{children} を上手く活用する事でバケツリレーを回避出来ないか検討するのが一番かなと思っています👍

https://qiita.com/akt_10/items/3ba2f2449fff9a97f9f5

今回 getServerSideProps で取得して、子componentに渡す方法を選んだ訳ですが、今のNext.jsだとAppRouterでReact Server Component (RSC)が使えるので、データの取得処理を各Componentで済ませる（データの取得を副作用とみなさない考え方）が主流になっていますので基本はサーバーで取得して、クライアントサイドからのfetchは徐々に少なくなってますね！

さらにServer Actionsが安定版になるとフォームのサブミット後の処理もサーバー側で処理するのが主流になってくると思うので Context や状態管理ライブラリも徐々に利用されるケースは減っていくだろうと思っています！

https://azukiazusa.dev/blog/nextjs-server-action/

[kuniyuki-f]

@keitakn

アドバイスありがとうございます！ ひとまず結論としては「getServerSidePropsで受け取った値をそのまま受け渡していって表示する」で実装進めていきますね👍

（以下は教えていただいた事柄に関する所感です！）

この記事 ではバケツリレーの回避策として useContext を解決策として上げていますが、自分的には Context はちゃんと使わないと無駄な再レンダリングが発生したりと結構難しいので本当に必要になるまで導入は避けたいのと、もし導入するにしてもそのあたりの問題が考慮されている Joutai とか valtio を使ったほうが良いかなと思います！

フロントエンドの状態管理って本当に難しいですよね👀 ライブラリや実装方法もたくさんあって自分はいつも悩みがちです😅（教えてもらった2つは初めて知りました！） 今回は不要なので、今後本当に必要になったら選定する、という感じですね！

もっと言うとこれらのライブラリを入れるのも最終手段で以下の記事のようにPropsで ReactNode 自体を受け取ったり、{children} を上手く活用する事でバケツリレーを回避出来ないか検討するのが一番かなと思っています👍

すごくわかりやすくて良い記事でした！ありがとうございます！ 個人的にはこの Composition というテクニックがしっくりきました。 別のところで React の開発（ Next.jsを使わない開発 ）もやっているので、必要に応じて実践してみたいと思います。 いきなり綺麗なコードは書けないかもですが、活用できるように頑張ります！

今回 getServerSideProps で取得して、子componentに渡す方法を選んだ訳ですが、今のNext.jsだとAppRouterでReact Server Component (RSC)が使えるので、データの取得処理を各Componentで済ませる（データの取得を副作用とみなさない考え方）が主流になっていますので基本はサーバーで取得して、クライアントサイドからのfetchは徐々に少なくなってますね！ さらにServer Actionsが安定版になるとフォームのサブミット後の処理もサーバー側で処理するのが主流になってくると思うので Context や状態管理ライブラリも徐々に利用されるケースは減っていくだろうと思っています！

Next.js そんなに進化してるんですか、すごいですね。。 アプリケーションの状態はできるだけサーバーサイドで持っておきたい、を実現してくれる機能なんですね👀

本件のケースでも、状態管理ライブラリを使うほどでもないという結論も出ましたので、ひとまず getServerSideProps で取得したデータを使って実装進めていきます！（ AppRouter の使用感もとても気になります、そのうち触ってみます！ ）

[kuniyuki-f]

完了の定義を満たしたので本Issueはクローズとします！