6日目のゴールと今日のテーマ
6日目のテーマは 「入力チェックの“質”を上げる」 ことです。
昨日までは、名前・コメントのような複数項目をチェックできるようになりました。
今日はそこから一歩進めて、
空チェック
文字数制限
条件分岐
エラー表示
という基本機能を使いながら、
「文字の種類をチェックする」
「複数の条件を組み合わせてもコードが崩れない」
「エラーの優先順位を設計する」
という“実用的なフォーム”に近い考え方を身につけます。
今日のテーマ①：文字の種類チェックを追加する
例：名前は「ひらがなだけOK」にしたい
現実のフォームでは、
「名前はひらがなだけ」
「数字だけ」
「英数字のみ」
など、文字の種類を制限することがよくあります。
今日はその中でも、
「ひらがなだけOK」
というチェックを追加してみます。
ひらがなチェックの基本
JavaScript では、正規表現（RegExp）を使うと文字の種類を判定できます。
ひらがなの範囲は「ぁ〜ん」です。
/^[ぁ-ん]+$/
これは、
先頭から末尾まで
ひらがなだけ
1文字以上
という意味です。
validate にひらがなチェックを追加する
名前欄だけに適用したいので、
validate に「ひらがなチェックをするかどうか」のフラグを追加します。
function validate(text, minLength, maxLength, options = {}) {
const trimmed = text.trim();
if (trimmed === "") {
return "未入力です。";
}
if (trimmed.length < minLength) {
return minLength + "文字以上で入力してください。";
}
if (trimmed.length > maxLength) {
return maxLength + "文字以内で入力してください。";
}
if (options.hiraganaOnly) {
const regex = /^[ぁ-ん]+$/;
if (!regex.test(trimmed)) {
return "ひらがなのみで入力してください。";
}
}
return "";
}
ここでの重要ポイントは、
「ひらがなチェックはオプション扱い」
にしていることです。
名前欄 → ひらがなチェック ON
コメント欄 → ひらがなチェック OFF
というように、項目ごとに柔軟に設定できます。
今日のテーマ②：validate を“設定で動く関数”に育てる
項目ごとにルールを渡す
名前欄のチェックはこう呼びます。
const nameError = validate(nameValue, 2, 20, { hiraganaOnly: true });
コメント欄はひらがな制限なし。
const commentError = validate(commentValue, 5, 100);
このように、
「チェックの中身は1つの関数」
「項目ごとの違いは設定で渡す」
という形にすると、
フォームが大きくなってもコードが崩れません。
今日のテーマ③：エラーの優先順位を設計する
どのエラーを先に見せるべきか？
例えば名前欄に「a」という文字が入っていた場合、
ひらがなではない
短すぎる
という2つのエラーが同時に起こります。
このとき、どちらを先に見せるべきでしょうか？
答えは 「短すぎる」 です。
理由はこうです。
ひらがなかどうか以前に、
「そもそも必要な文字数に達していない」
という根本的な問題があるからです。
validate の順番が大事
validate の順番はこうなっています。
空チェック
短すぎチェック
長すぎチェック
ひらがなチェック
この順番は、
ユーザーが直しやすい順番
になっています。
空 → まず何か書いて
短い → もう少し書いて
長い → 少し削って
ひらがな → 文字の種類を直して
この“直しやすさの順番”を意識することが、
入力チェックの設計ではとても重要です。
今日のテーマ④：エラー表示を「項目ごと＋全体」で扱う
errors オブジェクトを使う
昨日作った errors オブジェクトをそのまま使います。
const errors = {
name: validate(nameValue, 2, 20, { hiraganaOnly: true }),
comment: validate(commentValue, 5, 100),
};
項目ごとのエラー表示：
showError(nameErrorEl, errors.name);
showError(commentErrorEl, errors.comment);
全体エラー：
if (errors.name !== "" || errors.comment !== "") {
showFormError("入力内容に誤りがあります。");
return;
}
ここでの深掘りポイントは、
「エラーの状態を1つのオブジェクトにまとめておくと、全体の判定がとても楽になる」
ということです。
今日のテーマ⑤：入力中に“その項目だけ”エラーを消す
名前欄の入力中
nameInputEl.addEventListener("input", () => {
showError(nameErrorEl, "");
showFormError("");
});
コメント欄の入力中
commentInputEl.addEventListener("input", () => {
showError(commentErrorEl, "");
showFormError("");
});
ここでのポイントは、
「直している項目だけエラーを消す」
「全体エラーも消す」
という2つの動きです。
これにより、
送信 → エラー表示
入力開始 → エラーが消える（直していることを理解してくれる）
という自然なUXになります。
6日目のまとめと、7日目へのつなぎ
今日やったことを整理します。
ひらがなチェック（文字種チェック）を追加し、validate を“設定で動く関数”にした。
項目ごとに min / max / 文字種などのルールを柔軟に変えられるようになった。
エラーの優先順位を「直しやすさ」で設計する感覚を身につけた。
errors オブジェクトでフォーム全体のエラー状態を整理し、全体エラー表示も扱えるようになった。
入力中に項目エラー＋全体エラーを消すことで、UXを改善した。
7日目では、
「入力チェックアプリの設計を自分の言葉で説明できる」
という最終ステップに進みます。
最後にひとつだけ。
今日の中で、「あ、これ実用的だな」と感じたのはどこでしたか。
ひらがなチェックの追加か、エラーの優先順位の設計か、
それとも validate が“設定で動く道具”になった瞬間か。
その“気持ちよさ”が、あなたの設計センスの核になります。
