React界隈で話題になっている「React Server Components」についてまとめました！

どうもReact大好きCX事業部の片岡です！

今回はReact界隈で話題になっている「React Server Components」についての内容を意訳してみました。

元ネタ

話題になっているこちらの記事が元ネタです。

https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html

概要

Fetch APIでデータをやり取りすると、バケツリレーが発生します。例えば、Spotifyのアーティストページにはアーティストの情報と人気の曲とアルバム一覧が並びます。この時、人気の曲とアルバム一覧を取得するには、アーティスト情報を取ってこないといけません。そうすると、アーティスト情報を取得している間と人気の曲・アルバム一覧を取得するまでにクライアントサイドとサーバーサイドで無駄な待機時間が出来てしまいます。

GraphQL + Relayを使って解決する方法もありますが、なかなかそうはいかないケースもあります。

ならばFetchが必要なコンポーネントはサーバーサイドに移してしまおう！というコンセプトです。

利点

レンダリングが早くなる

サーバーサイドにコンポーネントのレンダリングを移すということは、サーバーサイドのリソースに直接アクセスできるので、データのやり取りがスムーズになり、レンダリングが早くなります。

クライアントサイドの容量が軽くなる

例えば、Fetchしたデータを元にdate-fnsで日付をフォーマットしたいとします。Fetchから日付のフォーマットをサーバーサイドで行うことで、フロントでdate-fnsを持つ必要がなくなります。実際に動画でビルドされた内容にdate-fnsが含まれていないことをデモしていました。

これは、date-fnsだけでなく、みんな大好きlodashやLaTeX形式をSVGに変換する等パッケージの容量を気にせずに使うことができるので、ユーザー体験と開発効率を引き上げることができると期待しています。

Stateをクライアントサイドで保持できる

SSRと違い、クライアントサイドで変更されたStateはそのままクライアントサイドで保持することができます。

例えば、検索フォームに文字列を入力された状態で、新しくメモを追加します。すると、追加した内容がそのまま検索フォームの文字列に従って検索されるようになります。これは、ページ全体が再ロードされるのではなく、再レンダリングが必要なコンポーネントだけ再レンダリングされるからできるワザですね！

サーバーサイドのリソースに直接アクセスできる

例えば、fsを使ってサーバー上のファイルに直接アクセスできるので、Markdownファイルを直接参照したり上書きしたりすることができます。

または、DBに直接アクセスしてCRUDをかけることもできます。これが良いのか悪いのかはひとまず置いておいて、柔軟に迅速にアプリケーションを作ることができます。

クライアント・サーバー両方で使える共有コンポーネント

クライアントサイドとサーバーサイド両方でコンポーネントを共有して使い回すことができる「共有コンポーネント（Shared Components）」があります。クライアントサイドで必要になった時にオンデマンドでダウンロードすることができます。

例えばメモのプレビュー画面があります。このプレビュー画面のコンポーネント自体はデータをFetchする必要があるので、サーバーサイドでレンダリングしています。そして、メモの内容を編集する際はプレビュー画面のコンポーネントをクライアントサイドでレンダリングします。この時プレビュー画面のコンポーネントをオンデマンドでダウンロードしています。

このように必要に応じたコンポーネントをクライアントサイド・サーバサイドの適切なところでレンダリングして描画することができます。

所感

• 子コンポーネントもサーバサイドでレンダリングされるため、コンポーネントの設計に気を配る必要がある
• Electronっぽい！（レンダラープロセスとメインプロセスをIPC通信でやり取りするような感じに似てる）
• OGPの対応方法が気になる
• インフラ構成どうすれば良いんだろう？どうやってスケールさせるんだろう？