040. hx-params（送信するデータを「賢く絞り込む」）

原理：不必要なデータは送らないという「引き算」の美学

多すぎる情報のノイズを消す

HTMXのボタンやフォームを送信するとき、HTMXは気を利かせて「その要素に関連する入力欄（<input> や <select>）の値」を自動的にかき集めてサーバーへ送ってくれます。これは基本的にはとても便利な機能です。

しかし、時には「今は検索ワードだけを送りたい。横にある、まだ入力途中の個人情報などは送ってほしくない」「このボタンを押した時は、どのデータも送らずに単にURLを叩くだけにしてほしい」という場面があります。不必要なデータを送りすぎることは、プライバシーの観点からも、サーバーの負担軽減の観点からも、あまり好ましくありません。

hx-params（パラズム / パラメータズ）属性は、通信の際に「どのデータを送るか、あるいは送らないか」を厳密に指定するための「フィルター」です。

実践：必要な情報だけを、潔く送る

1. すべてのパラメータを拒否する

「ボタンを押したという事実だけ」を伝え、フォームの中身などは一切送らない設定です。

<form hx-post="/api/ping">
    <input type="text" name="dummy" value="余計なデータ">

    <!-- 
      hx-params: "none" を指定することで、
      inputの中身を完全に無視して送信されます。
    -->
    <button type="submit" hx-params="none">
        合図を送る
    </button>
</form>

2. 特定の名前のデータだけを送る

大量の入力欄がある中で、一つだけをピックアップして送る例です。

<div hx-target="#result">
    <input type="text" name="search" id="q">
    <input type="text" name="extra_info" value="秘密の情報">

    <!-- search という名前のデータだけを狙い撃ちして送る -->
    <button hx-get="/search" hx-params="search">
        検索実行
    </button>
</div>

3. 特定のデータ「以外」を送る（除外設定）

「このパスワード欄だけは送らないで！」という場合に便利です。

<button hx-post="/save" hx-params="not password,not ss_number">
    データを送信
</button>

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

現状のチェック: 「今、このリクエストには何が同封されているだろう？」と想像（または開発者ツールで確認）します。
ルールの決定:
- *: 全部送る（デフォルト）
- none: 何も送らない
- 名前1, 名前2: これだけ送る
- not 名前: これ以外を送る
設置: 選んだルールを hx-params に書き込みます。

比較：デフォルト送信 vs hx-paramsによる制御

デフォルト（何もしない）

メリット: 何も書かなくていいので楽。大抵の場合はこれで正解。
デメリット: 知らぬ間に関係ないデータまでサーバーに送られ、サーバーログを汚したり、意図しない上書きバグを引き起こす可能性がある。

HTMXの hx-params

メリット: 「何が送られるか」を完全に掌握できる。安全で、かつ通信量が最小限になる。
デメリット: フォームに新しい欄を足し、その値が必要になったときに hx-params のリストを更新し忘れると、データが空っぽで届くというミスに繋がりやすい。

まとめ：初心者のための「身軽」な通信

hx-params を使いこなすと、あなたのWebアプリは「本当に必要なものだけをやり取りする」スマートなシステムへと進化します。

「none」と「*」から覚える: まずはこの両極端な使い分けから始めましょう。
セキュリティの補強に: not password のように書く癖をつけることで、万が一のデータの漏洩リスクを最小限に抑えられます。
サーバーに優しく: 通信データをダイエットさせることは、受け取る側のサーバーにとっても、回線にとっても、そしてバッテリーを気にするモバイルユーザーにとっても、嬉しいギフトになります。

送りすぎないことも、一つの技術。hx-params というフィルターを使って、無駄のない、研ぎ澄まされた通信を実現してください。これで、HTMXの「心臓」とも言える第2章「基本属性」はすべて終了です。第3章（041〜）では、これらの通信をより細かく「いつ・どうやって」引き起こすか、さらなるリクエスト制御の世界へと踏み込みます。