そもそも Server Component と Client Component は、何が違うのですか。
Server Component はサーバー側だけで実行され、そのJSはブラウザに送られません。DBやAPIキーに直接触れる代わりに、useState や onClick のような状態と操作は持てません。
面接官が見ているのは用語は知っているが中身を説明できない層の補強。
これは「参画したプロジェクトで、ほぼ全部のファイルの先頭に 'use client' が付いていました。どう判断しますか。」への追撃質問です。
よくある答えと、面談でどう見られるか
- Server Component はサーバーだけで実行され、そのJSはブラウザに送られない
その通りです。代わりに状態やイベントハンドラは使えません。 - Server Component は初回だけサーバーで動き、その後はクライアントで動く
「初回はサーバー、その後クライアント」はむしろ Client Component の挙動に近い説明です。Server Component はクライアントで動くことがありません。コードが送られないからです。 - Client Component の方が高機能なので、迷ったら Client にしておけばよい
機能の多寡ではなく、実行場所とコストの選択です。迷ったら Client にする方針だと、送るJSが増え続けます。既定が Server である理由がそこにあります。 - 違いはレンダリングの速さで、Server Component の方が描画が速い
描画速度そのものの話ではありません。実行場所が違い、その結果として送るJSの量や、秘密情報を扱えるかが変わります。
面接官は何を見ているか
- サーバーで実行され、JSがクライアントに送られない点を言えた
- 状態やイベントハンドラが使えないと理解している
- 使い分けの基準を1つ以上挙げられた
模範解答
Server Component はサーバー側だけで実行され、そのコンポーネントのJSはブラウザに送られません。DBやAPIキーに直接触れますし、送るJSが減るぶん初期表示が軽くなります。代わりに、useState のような状態も onClick のようなイベントハンドラも使えません。
Client Component は逆で、状態・イベント・ブラウザAPI（window、localStorage など）が使えます。そのぶんコードがブラウザに送られます。
App Router では layout と page が既定で Server Component です。公式の使い分けは、状態・イベントハンドラ・ライフサイクル・ブラウザAPI・カスタムフックが要るなら Client、データ取得や秘密情報の利用、JS削減が目的なら Server、という整理です。