🐈
RSCに関する知見（随時更新）
React Server Components（以下、RSC）、Server Actions（以下、SA）に関する知見（と意見）を随時更新していきます。
また、クライアントサイドは以下、CSと表記します。
- RSCは画面に表示する分しかクライアントに送信されないため、セキュリティ、パフォーマンス、ペイロードサイズの面で優れる。
- SAは「関数に対して、APIエンドポイントが自動生成される」と考えると良い。
- 実体はただのAPI呼び出しなので、セキュリティやパフォーマンスは実装次第。
- SAはRSCの関数内に定義しない方が良い。
- SAが親スコープの変数に依存すると、意図しないセキュリティやパフォーマンスの問題を生むと思われる。
- RSCのモジュールのスコープに定義し、exportはしない方が良い。つまり、SA自体は使いまわさない方が良い。
- そうすることで名前付けや依存関係の管理が楽になる。
-
next-safe-actionは使わない方が良いと思われる。
- せっかくtRPC（ライブラリレベルのサポート）からSA（言語レベルのサポート）に進化したのに、tRPCライクに書けても退化にしかならない。
- また、SAはJavaScriptの関数として実装できることが強みであるので、実装の自由度が著しく下がる＋学習コストもかかるライブラリに依存しない方が良い。
- CQRSの観点で考えると、傾向として「RSC → Query、SA → Command」の役割を担うことが多い。
- "あくまで傾向"なので、データ取得用のSAを作ることに問題は無い。
- RSC内でレンダリング中に更新処理を動かしても、ステートレスであれば、副作用があっても問題無いはず。（例：アクセスカウンター）
- **依存の向きは、「RSC / SA → クライアントコンポーネント」**にした方が良い。
- 逆をすると、予期せずクライアント用のバンドルにコードが混在してしまう。（大抵はエラーになりますが）
-
CSで動くコンポーネントが、SAを依存注入してもらう構成が多くなるし、スッキリする。
- SAの関数の型定義をクライアント側のコンポーネント（あるいはモジュール）に定義し、SA側からimportすると良い。
- CSのコンポーネントを使いまわすことになった場合に、インターフェースを統一できるメリットもある。
-
SEO関連はmeta、title、linkタグを任意の箇所に設置できるようになる。
- Next.jsだとHeadコンポーネントを使うと良い。
- 上記のやり方でないと、RSC内の処理で動的にドキュメントのメタデータを設定できないため、最も正しい方法と思われる。
-
URLのパス/クエリパラメータの取得は、Next.jsだとPage関数の引数で受け取れる。
- 検索するとミドルウェアを利用する方法が出てくるが、おそらく古い。
あれ、やはりまだまだ少ないですね。なるべく気付いた点は随時追加・更新していこうと思いますので、よろしくお願いします。
RSCを知らない方は、ハンズオンを作ったので是非試してみてください。（一部、上記の知見が反映されていない箇所もありますが、ご容赦ください）
Discussion