重い日付ライブラリを使っている表示用コンポーネントがあります。Client Component の中で使われています。どうしますか。
整形が表示のためだけなら、サーバー側で済ませます。Server Component の中で整形し、出来上がった文字列を props で渡せば、ライブラリはクライアントに送られません。
面接官が見ているのはサーバーへ寄せる具体策を出せるか。
これは「クライアントに送られる JavaScript を減らしたい。何から手をつけますか。」への追撃質問です。
よくある答えと、面談でどう見られるか
- サーバー側で整形して、出来上がった文字列を props で渡す
ライブラリが Client Component のモジュールグラフに入らなくなります。 - 遅延読み込みにする
バンドルからは消えませんし、表示のたびに読み込みが発生します。サーバーで済むなら、そもそも送らない方が良いです。 - 軽い日付ライブラリに差し替える
効果はありますが、送らずに済むならその方が確実です。差し替えは、クライアント側での再計算が本当に必要な場合の手です。 - サーバー側で整形する。ただしタイムゾーンの扱いは確認が要る
代償まで見えています。利用者の地域が複数にまたがる場合は設計判断になります。
面接官は何を見ているか
- 整形をサーバー側で済ませる案を出せた
- 整形済みの文字列を props で渡す、と具体化できた
- それで済むかを確認しようとした
模範解答
その整形が表示のためだけなら、サーバー側で済ませます。
Server Component の中で整形して、出来上がった文字列を props で Client Component に渡します。そうすればライブラリは Client Component のモジュールグラフに入らないので、バンドルから消えます。
確認すべきは、クライアント側で再計算が必要かどうかです。「3分前」のような相対表示を時間経過で更新したいなら、クライアントにもロジックが要ります。その場合は軽い実装に差し替えるか、更新頻度を落として妥協するかを検討します。
なお、タイムゾーンの扱いには注意が要ります。サーバーで整形するとサーバーのタイムゾーンが基準になるので、利用者の地域が複数にまたがる場合は、どちらで整形すべきかが設計判断になります。