Next.js App Routerを最適設計する方法

TL;DR

App Routerではサーバーコンポーネントを基本とし、状態管理、イベント処理、ブラウザAPIが必要な末端だけをクライアント化します。データ取得はサーバー側のfetchやORM関数へ寄せ、キャッシュ方式とレンダリング条件を用途に応じて明示します。

Transcript

はいどうもしですえ今回はですねNEXT JSAppleルータのベスト プラクティスについての動画を撮っていき たいと思いますNEXTJSっていうのが バージョンの13.4からえAppルー ターっていうのがね安定版になりましてで そこでまコンポーネントだったりとかま キャシュだったりレンダリングデータ フェッチあたりですねまそこら辺が ちょっと複雑になりすぎているのでまそこ をねちょっと1回えこの動画でまとめ直し たいと思いますなのでこの動画をですね1 本見ていただければですね今のNEXT JSのえまトレンドというかえベスト プラクティスえどういった感じでえ作って いけばいいのかNEXTJS実装していけ ばいいのかが大まかにま理解できるかなと 思いますのでまね公式のドキュメントとか ブログ記事... Read More

Key Insights

• サーバーコンポーネントはApp Routerのデフォルトであり、データ取得、配信量、端末依存、SEO、機密処理の観点から基本の選択肢として積極的に利用する。
• クライアントコンポーネントは、Reactのフック、クリックや入力のイベント処理、localStorageやwindowなどのブラウザAPIを必要とする場合に使う。
• クライアント境界は「use client」を付けたコンポーネントから下位へ広がるため、親階層で指定すると意図せず多数の子がクライアント側へ含まれる。
• クライアントコンポーネントはコンポーネントツリーの末端へ置くと影響範囲を抑えやすく、不要なJavaScriptバンドルの増加も避けやすい。
• コンポジションパターンは、クライアントコンポーネントがchildrenを受け取る構成により、その内側でサーバーコンポーネントを利用できる方法である。
• サーバーコンポーネントはサーバー側でHTMLを構成するため、クライアントで実行するJavaScriptを減らし、低スペック端末への依存を抑えやすい。
• Next.jsのfetchはキャッシュやレンダリングを制御でき、動画の説明時点ではバージョン15以降のデフォルトがSSR、14以前はSSGとされている。
• リクエストのメモ化は、同一URLかつ同一オプションのfetchが複数のコンポーネントから呼ばれた場合に重複リクエストを排除する仕組みである。
• 🎬 このチャンネルの他の動画:
  • AI時代にNext.jsの基礎を学ぶ方法
  • CursorのProject Rulesを設定する方法
  • AntigravityでAIアプリを作る方法
• 📺 このチャンネル: プログラミングチュートリアル

Questions & Answers

Q: App Routerでコンポーネントを設計する方法は？

サーバーコンポーネントを基本とし、ユーザー操作が必要な小さな部分だけをクライアントコンポーネントにします。状態管理、イベント処理、ブラウザAPIを使う箇所を切り出し、可能ならコンポーネントツリーの末端へ配置すると、クライアント境界の拡大を抑えられます。

Q: クライアントコンポーネントが必要なのはどのような場合ですか？

useState、useEffect、refなどのフック、onClickやonChangeなどのイベントハンドラー、localStorage、sessionStorage、window、documentといったブラウザAPIを使う場合です。タブ切り替えやハンバーガーメニューなど、クライアント側で状態を管理するUIも該当します。

Q: なぜサーバーコンポーネントを優先するのですか？

データベースやAPIの近くでデータを取得でき、クライアントへ送るJavaScript量を抑えやすいからです。サーバーでHTMLを構成することで端末性能への依存が減り、完全なHTMLを検索エンジンのクローラーへ提示しやすく、内部のクエリもクライアントへ露出させにくくなります。

Q: クライアント境界とは何ですか？

「use client」を付けたコンポーネントを境に、その配下へクライアント側の領域が広がることです。親コンポーネントへ指定すると、子ファイルに同じ宣言がなくても配下がクライアントコンポーネントとして扱われるため、境界をできるだけ末端へ置く設計が推奨されています。

Q: クライアントコンポーネント内でサーバーコンポーネントを使う方法は？

コンポジションパターンを使い、クライアントコンポーネントにchildrenを受け取らせ、その子としてサーバーコンポーネントを渡します。動画ではサイドメニューがchildrenをラップする例を示し、クライアント境界の内側でもサーバー側の構成を維持できる方法として紹介しています。

Q: App Routerでデータを取得する方法は？

サーバーコンポーネントから、Next.jsによって拡張されたfetchを利用するのが基本です。サーバーからAPIやデータベースへ近い経路でアクセスでき、fetchの第2引数に指定するオプションによって、キャッシュとレンダリングの方針を用途に合わせて変更できます。

Q: fetchのリクエストメモ化とは何ですか？

同一URLかつ同一オプションのfetchが複数回呼ばれたとき、重複するリクエストを排除する仕組みです。複数のコンポーネントが同じデータを要求しても、条件が一致すれば余分な取得処理を減らせるため、データ取得処理を一箇所へ無理に集約せずに構成できます。

Q: フォームは必ずクライアントコンポーネントにする必要がありますか？

必ずしも必要ではありません。入力中の状態管理やonChange処理が必要ならクライアントコンポーネントが適しますが、フォームのaction属性とServer Actionsを利用すれば、サーバーコンポーネントのまま処理する選択肢もあります。どちらを使うかはアプリケーションの仕様で決めます。

Summary & Key Takeaways

• コンポーネント設計では、デフォルトのサーバーコンポーネントを中心に構成し、useStateやuseEffectなどのフック、イベントハンドラー、ブラウザAPIが必要な部分だけに「use client」を付ける。フォームはクライアント化だけでなく、Server Actionsを利用してサーバー側で処理する選択肢もあり、アプリケーションの仕様に応じた判断が必要になる。

• サーバーコンポーネントは、サーバーからAPIやデータベースへ直接アクセスでき、クライアントへ送るJavaScript量を抑えやすい。サーバーでHTMLを構成するため端末性能への依存も減り、完全なHTMLをクローラーへ提示しやすくなる。APIキーやデータベースクエリをクライアント側へ露出させにくいことも利点である。

• データ取得では、Next.jsによって拡張されたfetchをサーバー側で利用し、レンダリングとキャッシュの方針をオプションで制御する。同一URLかつ同一オプションのリクエストはメモ化によって重複を排除できる。動画ではRequest Memoization、Data Cache、Full Route Cache、Router Cacheを分け、レンダリングとの関係を整理している。