136. Fragments vs Layouts（部分と全体の使い分け：画面構成の「黄金比」を見極める）

原理：二つのHTMLの姿

完璧な「全体」と、身軽な「一部」

HTMX開発において、サーバーは常に二つのパターンのHTMLを使い分けることになります。

Layout（レイアウト）: <html> や <body>、メニュー、フッターなどを含む、ページ全体の「器（うつわ）」。
Fragment（フラグメント/断片）: メインコンテンツの1行や、一つのボタン、カードなど、画面の「一部」を構成する部品。

「Fragments vs Layouts（フラグメント対レイアウト）」の考え方は、「どちらをいつ返せば、ユーザーとサーバーの両方が一番幸せになれるか？」という判断基準を持つことです。

実践：スムーズな切り替えのテクニック

1. 初回アクセスは「Layout」

ユーザーがURL（例：/shop）をブラウザに直接打ち込んだとき。サーバーは当然、メニューなども全て揃った「Layout」付きのHTMLを返します。これが「Webサイトとしての正装」です。

2. HTMX遷移は「Fragment」

すでにページが開いている状態で、HTMXのボタン（hx-get="/shop"）が押されたとき。サーバーは Layout を脱ぎ捨て、中身の「Fragment」だけを送ります。ブラウザはそれを今ある Layout の中に「シュッ」と流し込みます。これが「アプリとしての軽快さ」です。

3. ステップ・バイ・ステップ解説

ベースを定義する: 全てのページで共通の layout.html を作ります。
中身を切り出す: 各ページのメイン部分を fragment_home.html などの別ファイルにします。
自動で着せ替える: サーバー側の共通の仕組み（ミドルウェアなど）で、「hx-request があれば Layout をオフにする」という設定をします。これにより、個別のプログラムで「どちらを返すか」を意識する必要がなくなります。

比較：手動の切り替え vs フレームワークの支援

手動での切り替え

方法: 全ての URL に対して「if文」を書いて、Layout を入れるかどうか決める。
課題: 面倒で、記述漏れ（バグ）が起きやすい。

フレームワークの支援 (HTMXライブラリ等)

方法: 「このリクエストにはこのLayoutを適用する（ただしHTMXなら無視する）」というルールを一行書くだけ。
利点: プログラムがスッキリし、開発者は「中身（Fragment）」を作ることに専念できるようになります。

まとめ：初心者のための「Webの装い」

Fragments と Layouts を正しく使い分けることは、Webアプリに「強さ」と「速さ」を同時に与えます。

SEOの強さ: Layout がしっかりしていれば、検索エンジンはあなたのサイトを正しく評価できます。
ユーザーへの優しさ: Fragment だけを送れば、通信量が減り、スマートフォンのギガ（通信制限）にも優しいサイトになります。
メンテの楽さ: 「枠（Layout）」と「中身（Fragment）」が分かれているので、メニューのデザイン変更などが一瞬で終わります。

枠組みを守り、中身を研ぎ澄ます。この「全体と部分」の見事な調和を通じて、どんなデバイスから見ても美しく、そして電光石火の速さで動く、究極のHTMXアプリを完成させてください。次の記事では、なぜJSONではなくHTMLでやり取りするのかという本質「JSON vs HTML（137. JSON vs HTML）」をご紹介します。