行から詳細へ

業務の一覧で最もよく使われ、どのアプリでも作り直される操作です。 **このレコードを開き、作業し、戻り、次を開く。**作り直されたものの多くは同じ 3 つを失います — 中クリック、Back ボタン、そして一覧での居場所です。

npx @hypermedia-components/cli add row-detail
npx @hypermedia-components/cli validate page.html

recipe.html、expanded.html、機械検査されるサーバー契約が入ります。

別名: マスター詳細、ドリルダウン。

ライブデモ

同一性の列からレコードを開き、Previous / Next で辿ってください。並びは結果セットで、前後はサーバーが一覧クエリを再実行して解決するので、 3 行目と 4 行目の間のページ境界をクライアントに意識させずに越えます。

次に数行チェックして Open selected を押してください。形は同じ、並びが違います。歩行の途中で消えたレコードは、Next を生かしたままの 墓標ステップとして描画されます — このデモのスナップショットトークンは id をそのまま並べているので、レコードリンクの URL の seq= トークンに存在しない id(例: 4999)を差し込めば再現できます。トークンを読めなくなるまで壊すと、スナップショットは fail closed します: 一覧へ戻るリンク付きの 410 アラートで、黙って全件歩行に広がることはありません。

Open a record — or tick a few rows and press Open selectedto walk just those.

リンクは本物のリンク、同一性の列に

<tr class="hc-datagrid__row" id="row-4903" data-row-no="137">
  <td class="hc-datagrid__cell">
    <input class="hc-checkbox" type="checkbox" name="ids" value="4903"
           aria-label="Select order SO-4903">
  </td>
  <th class="hc-datagrid__cell" scope="row">
    <a href="/orders/4903" data-hc-row-link>SO-4903</a>
  </th>
  <!-- …データのセル… -->
</tr>

同一性の列が持ちます。行がであるものであって、後ろに付け足した動詞ではありません。ただのアンカーであるだけで、中クリック、⌘ クリック、アドレスのコピー、Back、キーボード、JS 無しの経路が手に入ります。クリックハンドラはそれらを下手に作り直すことになります。

installRowLink() が足すのは、アンカー自身にはできない 1 つだけ — 行のどこでも Enter で開く。矢印キーで辿り着いたグリッド利用者が期待する挙動です。編集が該当する場所では編集が勝ち（グリッドがエディタを開く前にイベントをキャンセルします）、Enter を自分で扱うコントロールはそのまま、修飾キー付きは「別のこと」の意思表示です。

data-hx-get にナビゲーションを飲み込ませないでください

<!-- 正しそうに見えて、実質モーダル専用の行になります -->
<a href="/orders/4903" data-hx-get="/orders/4903" …>SO-4903</a>

クリックは htmx が奪うので、レコードページそのものを指す hx-get は同一性リンクをモーダル専用の行に変えます。普通のクリックがページ描画に届くことは決してなく、href には中クリックでしか到達できず、画面は結局レコードはモーダルに住むと教えます。

同一性リンクへの重ね掛けが正当なのは、下の意図的なのぞき見としてだけです — hx-get は明示的なのぞき見バリアント(?peek=1)、href は正準のレコードページのまま、のぞき見はそのページへのリンクを含みます。クリックがレコードを開くを意味すべきなら、のぞき見には専用のコントロール(末尾列の小さなボタン)を与え、レコードの名前はただのリンクにしてください。

戻りこそ、みんなが落とす部分

一覧 URL は既に条件・ソート・列・ページを持っています。Back が復元できないのはどの行にいたかだけなので、詳細の一覧に戻るはその URL ＋ #row-<id> です。

/orders?f-ship=@week-start..&sort=-ship,order&page=4#row-4903

installDatagrid() がアクティブセルをそこに着地させ、グリッド自身のスクロールポートをスクロールします。キーボード利用者も目と同じ場所に到着します。

状態	復元方法
条件・ソート・列・ページ	一覧 URL
どの行か	`#row-<id>`
選択のチェック	選択から始まった旅のときだけ
スクロール位置	あえて復元しない — 行へのフォーカスの方が正確。1 行挿入されれば同じピクセル位置は別の行を指す
編集途中の入力	復元しない — 未保存の変更が離脱前に警告

詳細側はその URL を知る必要があります。アプリが正準の一覧を知っているか、リンクが ?from=<URL エンコード> で運ぶかです。運ぶ場合はサーバー側で検証してから（同一オリジン・既知のルート）リンクに出してください。未検証の from はオープンリダイレクトです。

「同じ」より「新しい」

ケース	戻り方
何も変更していない	Back。ブラウザ自身の履歴が最も安く正しい復元
保存した	一覧 URL ＋ `#row-<id>` へ `303`

このリダイレクトは形式ではありません。スナップショット復元は ユーザー自身の編集より前のデータを見せます。確実に気付かれる唯一の古い値であり、ページャの件数も道連れです。

のぞき見かページか：URL は 1 つ、描画は 2 つ

<a href="/orders/4903" data-hc-row-link
   data-hx-get="/orders/4903?peek=1"
   data-hx-target="#record-dialog"
   data-hx-swap="innerHTML">SO-4903</a>

href は正準のままなので、JavaScript が落ちても「死んだ行」ではなくフルページになります。オーバーレイは remote-dialog レシピで、中にフルページへのリンクを含みます — 閉じ込めるのぞき見は無い方がましです。

ページか、のぞき見か、ドッキングペインか

「詳細をどこに出すか」の答えはモーダルではありません。選択肢は 3 つで、 既定はページです。URL を持つのはページだけだからです。

形	どんなとき	理由
ページ（既定）	項目が多い、子グリッドがある、独自のアクションがある。ユーザーがそのレコードの中にいる	共有・ブックマーク・別タブ・JS 無しで到達できる唯一の描画
ドッキングペイン（分割）	レコードと一覧を何度も見比べる仕事（トリアージ、突合）	両方が生きたまま。オーバーレイで隠れるものが無い
のぞき見（モーダル）	見て戻るだけ（1 項目の確認、承認して閉じる）。短いレコード	一覧の居場所を保てる。スクロールが要る／タブや子グリッドが生えた時点で、それはページになりたがっている

業務ソフトウェアでモーダルは 3 つの中で最も少数派で、それは偶然ではありません。Gmail はレコードを開くと画面を置き換えます。SAP Fiori は一覧とレコードを列に分割します。Salesforce も ServiceNow もレコードにはページを与えます。これらの製品でモーダルが担うのは短く完結した作業（1 件作る、確認する、1 項目直す）であって、「レコードそのもの」ではありません。レコードは仕事が起きる場所で、仕事には広さと URL と自前のエラー面が要るからです。

避けるべき失敗は具体的です。**URL を持たないモーダル。**レコードを見ているのにアドレスバーが一覧のままなら、Back は開いていないものを閉じ、同僚に送るリンクは違う画面を指し、再読込で居場所が消えます。URL を push し、URL から自分を復元できるモーダルは正当な描画です。そうでないモーダルは、詳細画面の服を着た行き止まりです。

のぞき見を正直に保つ規則が 2 つあり、破れば両方とも不具合です。

行の href はページであり、のぞき見は data-hx-get でその上に重ねます。ダイアログ経由でしか辿り着けないレコードはリンクできません。同僚から最も多く求められるのがそれです。
**のぞき見の中にページへのリンクを置く。**閉じ込めるのぞき見は、無い方がましです。

連続して辿る

1 件開くのは仕事の半分です。業務は待ち行列です。詳細は前へ／次へを持ち、その並びはユーザーが見ていたものです。

並び	ワイヤ
結果セット（既定）	`?seq=list&i=<序数>` — サーバーが一覧クエリを再実行して前後を解決するので、「次へ」はページ境界をクライアントに意識させずに越えます
選択	「選択した12件を開く」が `ids` チェックボックスを送信 → `POST /orders/selections` → トークン付きで `303`

トークンが指すのは順序付きスナップショットで、画面もそう述べます（12 件中 3 件目 — 14:32 時点の選択）。消えたレコードは墓標のステップであって壁ではありません（最初の欠落で止まると、データが動いているときにこそ信用できなくなります）。トークンの失効は fail closed（410 ＋一覧への導線）で、黙って全件歩行に広がることはありません。

連続移動をどこに置くか — 下部ではない理由

前へ／次へはレコードのヘッダーに置きます。同一性の表示と「一覧に戻る」の隣です。下にある内容のページングではありません。

「次へ行く」判断は、たいてい最後まで読む前に下されます。ちらっと見て、判断して、次へ。スクロールしないと届かないコントロールは、 2 秒の判断を毎回スクロール込みにします。
詳細の本文はスクロールするので、下部のコントロールは流れて消える （待ち行列が長いときにこそ役に立たない）か、固定の帯をもう 1 本用意することになります。滅多に到達しない位置のために払うクロームです。
保存後の 303 はユーザーを先頭に着地させます。次の移動は、いまいる場所にあるべきです。

長い詳細では、下部に副次的な複製として置いても構いません。どちらも同じリンクなので同期する状態はなく、主役はヘッダー側のままです。

**そのヘッダーの中の並びにも意味があります。**しかもこれは、メールクライアントが既に全員に教えている並びです。

← 一覧に戻る          …レコードの同一性…          1 / 15,129  ‹  ›

出口は先頭。人が「ここから出たい」ときに見るのはそこだからです。
移動（位置の表示 → 前へ／次へ）は末尾。ポインタが既にいる側で、かつ「次へ進む」が頻度の高い行為だからです。

一覧の移動用の帯と同じ規則です。いまどこにいるかとどこへ行くかは末尾、出口は先頭。

詳細の中のグリッドは自分でページングする

詳細画面は自分のグリッドを持ちます（明細・出荷・履歴）。それぞれが 自分の直下でページングし、ページ全体のフッターには置きません。 3 つのグリッドがある画面のページ全体のページャは、どのグリッドをめくるのかを言えません。一覧テンプレートの規則（移動は、それが動かすデータの下に）は、そのデータについての話であって、ページについての話ではありません。

残りの高さを取るのは hc-fill を持つグリッドだけで、他は自分の上限・自分のページャ・自分の空状態を保ちます。

つまり詳細画面の下部が持つのはその画面のアクション（保存・取消）であって、移動ではありません。