HTMLフォーム検証の低調な活用
- HTMLフォームには強力な検証メカニズムがあるが、あまり使われていない。多くの人がこれをよく知らない。これは設計上の欠陥が原因かもしれない。
属性、メソッド、そしてプロパティ
- 空の入力を防ぐために
required 属性を追加できる。
- 入力に制約を追加する方法は3つある:
- 特定の
type 属性値を使う: "email", "number", "url"
"pattern" や "maxlength" のような他の入力属性を使うsetCustomValidity DOMメソッドを使う: 任意の検証ロジックを作成し、複雑なケースを処理できる最も強力な方法。
命令型APIの微妙さ
setCustomValidity APIはメソッドとしてしか提供されておらず、使いづらい。- たとえば、入力が空のときにフォーム送信を防ぐため、
required 属性と同じ機能を実装できる。
- 初期レンダリング時に入力が空なら、無効に設定しておく必要がある。
ボイラープレートの問題
- 初期値を検証する方法が煩雑。
- 検証ロジックが
onChange ハンドラと初期レンダリング段階で重複する。
useRef + useLayoutEffect + onChange の組み合わせは複雑。
欠けている部分
custom-validity 属性が必要。- 宣言的フレームワークで入力検証を強力に定義できる。
非同期検証の力
- ユーザー名入力が 未使用の場合にのみ有効 であるべきケースを扱える。
- サーバーへの非同期呼び出しが必要で、中間状態も必要になる。
実装
verifyUsername 関数を使ってユーザー名の一意性を確認する。useQuery を使ってサーバーリクエストの状態を管理する。customValidity 属性を使って非同期検証フローを説明する。
パスワード確認フォーム
- 入力したパスワードを繰り返し入力させるフォームを実装する。
- 2つの入力フィールドが一致するかを確認して検証する。
結論
setCustomValidity はさまざまな検証要件を満たせる。- 強力なAPIこそが真の力をもたらす。
- HTML仕様にこの機能が追加されることを期待する。
GN⁺のまとめ
- HTMLフォーム検証は強力だが、十分に活用されていない。これはAPIの複雑さが原因かもしれない。
setCustomValidity メソッドは、複雑な検証ロジックを処理できる強力なツール。- 非同期検証のような複雑なシナリオに対応できる方法を提示している。
- この記事は、開発者がHTMLフォーム検証をよりうまく活用できるようにする有用な情報を提供している。
1件のコメント
Hacker Newsのコメント
Webブラウザでは依然として組み込みのHTMLバリデーションメッセージのスタイルを変更できず、ChromeとFirefoxはOSプラットフォームのUIガイドラインにも従っていないため、プロジェクトの美観と衝突する
<select multiple>の非効率な使い方への不満がある特定の
type属性値（例:email、number、url）を使うと、モバイルで最適なキーボードが表示され、ユーザー体験を大きく向上させられる仕様を書く人たちは実際の利用とかけ離れており、単純なものには向いているが、複雑なフォームでは自前で作るほうがよい
フォームの基本的なシンプルさを見落としていたことを後悔しており、他の人の視点を共有してくれたことに感謝している
チェックボックスにラベルがある場合、ラベルに
for属性を追加して、ラベルをクリックしてチェックボックスを有効化/無効化できるようにしてほしいという要望があるReactを使わないシンプルな例の紹介
HTMLフォームのバリデーションは素晴らしいが、Firefox for Androidでは動作しないという大きな問題がある
スタイル変更可能なバリデーション機能を提供するフレームワークやライブラリは多いので、あえて苦労する必要はない
バリデーションの過剰使用には注意すべき
2FA入力に
type=passwordを誤って使うサイトは、パスワードマネージャーやブラウザを混乱させる