065. Request Filtering（リクエスト・フィルタリング：送信する前に「やるべきか」を判定する）

原理：無駄な通信を入り口で止める「最終チェック」

サーバーに聞く前に、ブラウザで考える

HTMXは、トリガーが引かれると元気よくサーバーへリクエストを飛ばします。しかし、何でもかんでもサーバーに聞きに行くのが正しいとは限りません。

例えば： - 検索窓に、さっきと同じ言葉が入っている。 - 入力欄が空っぽのまま「送信」が押された。 - 特定のチェックボックスに印が付いていない。こういう時は、サーバーにリクエストを送るまでもなく「今は何もしなくていいよ」とブラウザ側で判断すべきです。

「リクエスト・フィルタリング」は、通信が始まる直前に「本当に送っていいの？」と条件を確認し、不要ならその場で通信をキャンセルする技術です。

実践：条件付きで「通信をさぼる」賢い実装

1. 前回の値と同じなら送らない（changed）

これは第3章で何度も出てきた、HTMXの最も基本的で強力なフィルタリングです。

<!-- 
  changed: 
  入力内容が「前回の通信時」から変わっていなければ、
  keyupイベントが起きてもリクエストを送りません。
-->
<input type="text" hx-get="/search" hx-trigger="keyup changed">

2. JavaScriptの条件式で判断する（インライン・フィルター）

もっと複雑な条件、例えば「3文字以上入力した時だけ送る」といった指定も、HTMXなら属性一つでカバーできます。

<!-- 
  hx-trigger に [ ] を使ってJavaScriptの条件を書きます。
  this.value.length > 3 が true の時だけ、リクエストが飛びます。
-->
<input type="text" name="q" 
       hx-get="/api/search" 
       hx-trigger="keyup[this.value.length > 3]">

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

無駄の発見: 「この操作、中身がこうなってる時はサーバーを叩く必要がないな」という条件を見つけます。
簡易フィルター（changed）: 入力内容に変化があったかだけを気にするなら、changed キーワードを hx-trigger に書き足します。
詳細フィルター（条件式）: [ ] という魔法の四角い括弧を使って、JavaScriptの短い条件式を書き込みます。

比較：サーバーサイド・バリデーション vs フィルタリング

サーバーサイド・バリデーション

場所: サーバーの中。
特徴: リクエストは一度飛んでくる。サーバーが「ダメだよ」というHTMLを返して、ブラウザがそれを表示する。
役割: セキュリティ上の最終防衛線。

HTMXのリクエスト・フィルタリング

場所: ユーザーのブラウザ。
特徴: リクエストそのものが飛ばない。 サーバーは何も知らない。
役割: ネットワークの節約と、ユーザーへの超速レスポンス。

まとめ：初心者のための「賢い節約術」

リクエスト・フィルタリングを使いこなすと、あなたのWebアプリは「無駄撃ちをしない、効率的なプロフェッショナル」へと進化します。

「changed」は親友: 検索や入力の連動を作る時は、とりあえず changed を付けておく。これだけで通信の無駄が半分以下になることもあります。
JavaScript への扉: [ ] を使うことで、これまで「HTMXだけでやる」ことにこだわっていた世界が、ちょこっとだけJavaScriptの力を借りることで何倍にも広がります。
UXの静かな向上: サーバーとの通信が減れば、ページ全体の動きがより軽くなり、サクサクとした心地よさが生まれます。

送る前に、一呼吸。changed や [...] を使って、本当に価値のあるリクエストだけをサーバーへ届けてください。これで第3章「リクエスト制御」は幕を閉じます。第4章（066〜）では、サーバーから受け取った「宝物（HTML）」を、画面上のどこへどうやって馴染ませるか、DOM更新のさらなる深淵へと進みます。