フォームの送信処理はどう実装しますか。
'use server' を付けた async 関数を form の action に渡します。APIエンドポイントを別途作らずに済み、JSが無効でも送信できる形になります。実体はサーバー上の関数です。
面接官が見ているのはServer Actions を選択肢として持っているか。
よくある答えと、面談でどう見られるか
- 'use server' を付けた async 関数を form の action に渡す
Server Function です。API エンドポイントを別途作らずに済みます。 - Route Handler を作って、クライアントから fetch する
動きますし、外部から叩かれる口が要るならこちらが正解です。ただし自分の画面から送るだけなら、エンドポイント設計の手間が増えるだけになります。 - Client Component で状態を持ち、onSubmit の中で API を呼ぶ
従来型の作りで、間違いではありません。ただし送信中・エラー・成功の状態を自前で持つことになります。面談では「App Router なら他にどう書けるか」を聞かれます。 - Server Component の中に onSubmit を書く
Server Component ではイベントハンドラを渡せません。ハンドラは関数なので、クライアントへ送れないためです。
面接官は何を見ているか
- Server Function（'use server'）を挙げた
- API ルートを作らずに済む点に触れた
- 更新後の再検証まで意識している
模範解答
Server Function を使います。'use server' を付けた async 関数を form の action に渡すと、送信時にサーバー側でその関数が実行されます。
利点は、API エンドポイントを別途作らなくて済むことと、クライアント側で fetch を書いて状態を管理する手間が減ることです。
注意点として、Server Function は更新（ミューテーション）のための仕組みです。公式も「サーバー側の状態を更新するためのもので、データ取得には推奨しない」と明記しています。取得は Server Component で await する形が基本です。
更新したら、表示しているキャッシュを捨てる処理までがセットです。ここを忘れると「保存したのに一覧が変わらない」になります。
ここからどう深掘りされるか
この問いに答えられた場合、面談は次の質問に進みます。
観点をすべて押さえられた場合
Server Function のセキュリティで、気をつけることは何ですか。一部しか触れられなかった場合
更新したのに一覧の表示が変わりません。何を疑いますか。触れられなかった場合
更新したのに一覧の表示が変わりません。何を疑いますか。