IT-Q

データ取得も Server Function でやってはいけませんか。

できますが推奨されていません。React 公式は、Server Function はサーバー側の状態更新のために設計されており、データ取得には推奨されないと明記しています。

面接官が見ているのは公式が明示的に非推奨としている点を知っているか。

これは「Route Handler(route.ts)と Server Function は、どう使い分けますか。」への追撃質問です。

よくある答えと、面談でどう見られるか

  • 推奨されていない。逐次処理になり、結果をキャッシュする手段も無いため
    React の公式に明記されています。取得は Server Component で await するのが基本です。
  • 問題ない。サーバーで動くので取得にも使える
    動きはしますが、公式が明示的に非推奨としています。並行に走らず、結果もキャッシュできません。
  • 推奨されていない。取得は Server Component で直接 await する
    そちらならメモ化もキャッシュも効きます。
  • 推奨されていないが、クライアントから取り直したい場合は仕方なく使う
    気持ちは分かりますが、まず URL の検索パラメータを変えてサーバーで取り直す形を検討します。状態が URL に乗るので共有もリロードも自然に動きます。

面接官は何を見ているか

  • 取得には推奨されていないと知っている
  • Server Component で await する形が基本だと言えた
  • 理由(逐次処理・結果がキャッシュされない)に触れられた

模範解答

できますが、推奨されていません。

React の公式リファレンスに「Server Function はサーバー側の状態を更新するために設計されており、データ取得には推奨されない。したがって、実装フレームワークは通常一度に1つのアクションを処理し、戻り値をキャッシュする手段を持たない」と明記されています。

つまり2つの問題があります。複数の取得が並行に走らず順番待ちになること、そして結果をキャッシュできないことです。

取得は Server Component の中で直接 await するのが基本形です。そちらならメモ化もキャッシュも効きます。

クライアント側の操作(絞り込みなど)で取り直したい場合は、URL の検索パラメータを変えてサーバーで取り直す形にすると、状態が URL に乗るので共有もリロードも自然に動きます。