htmx を使用した段階的強化フォームの構築

htmx を使用した段階的強化フォームの構築 2026年6月25日; LLM生成テキストなし 最近、多くのインタラクティブ性を持つ新しいフォームを ties 用に構築しました。これはブックマークを編集し、リストに接続するためのものです。 ブックマークを編集し、ブックマークされたウェブサイトから取得したタイトルに名前を変更してから、ブックマークを追加するリストを検索するフォームのスクリーンキャスト。 この機能は段階的強化を使用しています。JavaScript がなくても機能しますが、JavaScript が有効な場合は htmx を使用していくつかの利便性を追加します。この記事では、私のアプローチを説明し、このスタイルの UI を構築する際に考慮すべき点をいくつか紹介します。 一時的な状態 JavaScript なしで機能するインターフェイスは、シングルページアプリケーションとは根本的に異なります。ユーザーの操作に応答して UI を更新するには、サーバーへの往復（通常は <form> または input 要素によって開始される）が必要になることがよくあります。ユーザーがタスクを完了し、データベースに何かを保存する前に、「一時的な状態」があります。これは、ユーザーが入力した、まだ永続化されていない、この往復を乗り越える必要がある入力です。上記のフォームからの例としては、ブックマークの新しい名前が挙げられます。ユーザーが「名前変更」ボタンを押すと、名前がサーバーに送信され、検証エラーがある場合、サーバーはエラーを示す応答を返します。応答にはユーザーの入力値が含まれているため、再度入力する必要がありません。SPA では、一時的な状態は JS メモリに存在し、それを管理するために大量の依存関係を持つライブラリを使用することになります。JavaScript なしで済ませるため、一時的な状態を管理するには、それぞれトレードオフのある古典的な HTML 機能を使用する必要があります。この一時的な状態がシステム全体でどのように流れるかを考えることは、複雑なインタラクションを HTML にマッピングするのに役立ちます。 フォームの値 これは例の「名前変更」フィールドに使用され、最も一般的に使用されるものです。フォームが送信されると、サーバーはこれらの値を受け取り、応答に含めることができるため、ユーザーがサーバーとやり取りしても消えません。これはシンプルで、おそらく多くのユーザー入力に対してすでに使用しているテクニックです。このテクニックの欠点は、ユーザーがページをリロードすると値が消えることです。もう 1 つの欠点は、値は 1 つのフォームに対してのみ送信されることです。ページに複数のフォームがある場合、他のフォームの値は送信時に消えます。たとえば、上記のブックマーク編集フォームは 2 つのフォームに分割されています。1 つはブックマークの名前変更用、もう 1 つはリストの割り当て用です（分割する理由は後で説明します）。htmx を使用してこれを回避できます。これにより、JavaScript を持たないユーザーは正常に機能低下を体験できます。 クエリパラメータとパス 状態をパスまたはページのクエリパラメータに入れると、ページのリロードを乗り越えることができます。ブックマークやリンクの共有なども乗り越えることができます。これは、たとえば検索クエリ、上記のフォームの「リストを検索して接続する」入力などに適しています。パスとクエリパラメータを設定する最も一般的な方法は、リンクの href 属性とフォームの action 属性です。method="GET" 属性を持つフォームを使用することもできます。これにより、そのフォームのすべての入力値がクエリ文字列に入力されます。最後に、submit ボタンの formaction 属性を使用して、特定の submit ボタンが押されたときにのみフォームのパスとクエリパラメータを変更できます。これは非常に便利です。この記事を書いている間に知ったばかりです。 どのボタンが押されたかを検出する ties の新しいフォームを構築していて驚いたことの 1 つは、Enter キーが何をするかを制御できないことです。それは、入力に関連付けられたフォームの最初の submit ボタンを送信するだけです。アクセス可能なフォームはキーボードで制御できるものでなければならないため、ブックマーク編集フォームを 2 つに分割しました。これにより、リスト検索入力で Enter キーを押してもブックマークの名前が変更されないようにしました。ユーザーがフォームを送信したときにどのボタンを押したかを知るには、ボタンの formaction 属性を使用してフォームが送信するパスを変更できます。または、ボタンの名前と値の属性を設定して、そのボタンが押されたときにサーバーに特定のフォーム値を送信することもできます。 段階的強化 JavaScript を使用しないユーザーをサポートするために、まず htmx なしで機能全体を作成するのが最も簡単だと考えています。これにより、JavaScript なしでは不可能であることが判明した場合に、後でリファクタリングする必要があるような状況に陥るのを避けることができます。それが完了したら、JavaScript が利用可能な場合にエクスペリエンスを向上させるために、htmx を少し追加します。上記の例では、ユーザーが Enter キーを押さなくても検索結果が表示される「アクティブ検索」や、サーバーからの応答を待っていることを示す小さなスピナーが含まれています。このアプローチに従うと、実際に必要な htmx の量が非常に少ないことに驚くことがよくあります。後で変更をテストするときは、ブラウザの開発者ツールを使用して JavaScript を無効にするか、hx-disable 属性を追加します。 hx-target htmx スワップのスコープを正しく設定する方法をまだ模索しています。ページの一部が狭すぎると更新され、ページの他の部分に古いデータが表示されるというバグをよく見つけました。帯域外スワップでこれを解決しようとすると、エラーが発生しやすく、メンテナンスが非常に困難になるように感じます。将来的に壊れる可能性が最も低いので、通常はページ全体をスワップすることになります。これの欠点は、スワップ中にユーザーの入力が失われることがあることですが、それはまれで、通常は許容できます。 さらなる情報 以上です。この記事から何か役立つことを持ち帰っていただけたなら幸いです。このアプローチが次のプロジェクトに適しているかどうかを知りたい場合、またはすでに html/htmx を使用していてさらに学びたい場合は、お気に入りのリソースをいくつか紹介します。 Alexander Petros のブログ「Unplanned Obsolescence」は宝の山です。「Less htmx is more」と「Who’s Afraid of a Hard Page Load?」が良い出発点です。 How I use HTMX with Go and Django + htmx patterns は、バックエンドで htmx を使用するパターンについて説明しています。これらは他の言語やエコシステムにもうまく翻訳できます。 If not React, then what? は、サーバーレンダリングされた HTML や htmx が構築中のプロジェクトに適しているかどうかを判断するのに役立ちます。 Resilient Web Design は、堅牢なウェブサイトの設計に関する信じられないほどよく書かれた本です。視覚的な意味合いよりも、全体的な意味合いでの設計に関するものであり、私の多くの技術的な選択に影響を与えました。このリストから 1 つ読むなら、これにしてください。 Plain Vanilla Web は、料理本形式で一般的なユースケースを紹介する、おそらくあなたが知らないブラウザの最新機能のリファレンスです。