なぜ Promise にする必要があったのだと思いますか。
リクエスト時にしか確定しない情報だからです。同期的なオブジェクトとして渡す設計では、値が揃うまでレンダリング全体を待つしかありません。Promise なら待つ範囲を選べます。
面接官が見ているのは変更の理由まで踏み込めるか。暗記か理解かが出る。
これは「動的ルートで params.slug を読もうとしたら、期待した値が入っていませんでした。何を疑いますか。」への追撃質問です。
よくある答えと、面談でどう見られるか
- リクエスト時にしか確定しない情報なので、待機を使う場所まで遅らせられるようにするため
cookies() や headers() が非同期になったのと同じ方向の変更です。 - 型を厳密にするため
型のためではありません。レンダリングの進め方に関わる変更です。 - 値に依存しない部分を先に描画して送り出せるようにするため
静的な部分を先に出す設計と地続きです。理由まで説明できると理解が伝わります。 - 非同期処理に統一して API を分かりやすくするため
結果として統一されてはいますが、目的は整合性ではなく「確定を待つタイミングを遅らせる」ことです。
面接官は何を見ているか
- リクエスト時にしか分からない情報だから、と関連づけた
- 同期的だとその時点で待つしかない、と説明できた
- 静的に描ける部分を先に出す、という発想に繋げられた
模範解答
params や searchParams が、リクエスト時にしか確定しない情報だからです。
同期的なオブジェクトとして渡す設計だと、レンダリングを始める時点で値が揃っている必要があります。つまり「確定するまで待つ」しか選択肢がありません。
Promise にしておくと、値を実際に使う場所まで待機を遅らせられます。結果として、その値に依存しない部分は先に描画して送り出せます。静的な部分を先に出して、リクエスト依存の部分を後から流し込む、という設計と地続きの変更です。
同じ方向の変更として cookies() や headers() も非同期になりました。個別の API 変更として覚えるより、「リクエスト依存の情報を、必要になるまで待たない形に揃えた」と理解しておく方が、次の変更にもついていけます。