JavaScript | 1 日 90 分 × 7 日アプリ学習：入力チェックアプリ（初級編）

3日目のゴールと今日のテーマ

3日目のテーマは「条件分岐とエラー表示を、“ちょっと現実に近いフォーム”レベルまで育てること」です。
機能としてはまだ同じです。

未入力警告（空チェック）
文字数制限
エラー表示

ただし今日は、

「何がダメなのか」をもっとハッキリさせる。
チェックを少しだけ増やしても、コードがぐちゃっとしないようにする。
エラー表示の“見せ方”も、設計として意識してみる。

というところまで踏み込みます。

2日目までの「今の型」をもう一度整理する

validate と handleSubmit の役割分担

2日目で作った基本パターンは、ざっくりこうでした。

const inputEl = document.getElementById("input-text");
const errorEl = document.getElementById("error-message");
const submitButton = document.getElementById("submit-button");

const maxLength = 20;

submitButton.addEventListener("click", handleSubmit);

function showError(message) {
  errorEl.textContent = message;
}

function validate(text) {
  const trimmed = text.trim();

  if (trimmed === "") {
    return "未入力です。何か入力してください。";
  }

  if (trimmed.length > maxLength) {
    return maxLength + "文字以内で入力してください。";
  }

  return "";
}

function handleSubmit() {
  const value = inputEl.value;
  const errorMessage = validate(value);

  if (errorMessage !== "") {
    showError(errorMessage);
    return;
  }

  showError("");
  alert("入力ありがとうございます！");
}

const inputEl = document.getElementById("input-text");
const errorEl = document.getElementById("error-message");
const submitButton = document.getElementById("submit-button");

const maxLength = 20;

submitButton.addEventListener("click", handleSubmit);

function showError(message) {
  errorEl.textContent = message;
}

function validate(text) {
  const trimmed = text.trim();

  if (trimmed === "") {
    return "未入力です。何か入力してください。";
  }

  if (trimmed.length > maxLength) {
    return maxLength + "文字以内で入力してください。";
  }

  return "";
}

function handleSubmit() {
  const value = inputEl.value;
  const errorMessage = validate(value);

  if (errorMessage !== "") {
    showError(errorMessage);
    return;
  }

  showError("");
  alert("入力ありがとうございます！");
}

ここでの分担はこうでした。

validate
→ 入力がOKかどうかを判断し、ダメなら「何がダメか」を文字列で返す。

handleSubmit
→ 入力を取り、validate に投げ、エラーがあれば表示、なければ成功処理。

showError
→ エラー表示専用の小さな関数。

この骨組みは、3日目以降もそのまま使い続けます。

3日目の一歩目：「条件を1つ増やしても崩さない」

新しい条件：最小文字数もチェックしてみる

これまでの条件は「空」と「最大文字数オーバー」でした。
ここに「短すぎるのもNG」というルールを足してみます。

例えば、

1文字以上は必須（空はNG）。
3文字以上ないとNG（短すぎる）。
20文字を超えてもNG（長すぎる）。

現実のフォームだと、「名前は2文字以上で」とか「コメントは10文字以上で」とかありますよね。
そのイメージです。

minLength を導入する

まずは設定値を追加します。

const minLength = 3;
const maxLength = 20;

const minLength = 3;
const maxLength = 20;

validate をこう変えます。

function validate(text) {
  const trimmed = text.trim();

  if (trimmed === "") {
    return "未入力です。何か入力してください。";
  }

  if (trimmed.length < minLength) {
    return minLength + "文字以上で入力してください。";
  }

  if (trimmed.length > maxLength) {
    return maxLength + "文字以内で入力してください。";
  }

  return "";
}

function validate(text) {
  const trimmed = text.trim();

  if (trimmed === "") {
    return "未入力です。何か入力してください。";
  }

  if (trimmed.length < minLength) {
    return minLength + "文字以上で入力してください。";
  }

  if (trimmed.length > maxLength) {
    return maxLength + "文字以内で入力してください。";
  }

  return "";
}

ここでの大事なポイントは「順番」です。

まず“完全な空”を弾く。
次に「短すぎる」を見る。
最後に「長すぎる」を見る。

こうしておくと、ユーザーが「何から直せばいいか」が分かりやすくなります。

条件分岐の順番を“意識して決める”練習

「どの順番でも動く」けど、「読みやすさ」が違う

理屈だけなら、順番を変えてもコードは動きます。

if (trimmed.length > maxLength) { ... }
if (trimmed.length < minLength) { ... }
if (trimmed === "") { ... }

if (trimmed.length > maxLength) { ... }
if (trimmed.length < minLength) { ... }
if (trimmed === "") { ... }

でも、これだと挙動が変になります。

未入力なのに「長すぎます」と言われる場合が出る。
エラーが「ユーザーの感覚」とズレる。

だから、「ユーザーにどう伝えるか」を考えながら順番を決めます。

1. そもそも何も書いてない（最優先で教えたい）。
2. 書いてはいるが、「短すぎて意図が伝わらない」。
3. たくさん書きすぎて、「制限を超えている」。

こういう“人間側の感覚”に合わせて if の順番を決める。
これ、立派な設計です。

条件を増やした validate を読みやすく保つ

「チェック1つ＝if 1つ」という形を守る

今の validate はこうなりました。

function validate(text) {
  const trimmed = text.trim();

  if (trimmed === "") {
    return "未入力です。何か入力してください。";
  }

  if (trimmed.length < minLength) {
    return minLength + "文字以上で入力してください。";
  }

  if (trimmed.length > maxLength) {
    return maxLength + "文字以内で入力してください。";
  }

  return "";
}

function validate(text) {
  const trimmed = text.trim();

  if (trimmed === "") {
    return "未入力です。何か入力してください。";
  }

  if (trimmed.length < minLength) {
    return minLength + "文字以上で入力してください。";
  }

  if (trimmed.length > maxLength) {
    return maxLength + "文字以内で入力してください。";
  }

  return "";
}

見てほしいのは、「1つの if が1つのルールだけを見ている」ことです。

空チェック。
短すぎチェック。
長すぎチェック。

これがもし、

if (trimmed === "" || trimmed.length < minLength) {
  // 何かのエラー
}

if (trimmed === "" || trimmed.length < minLength) {
  // 何かのエラー
}

みたいな書き方になると、

空なのか短いのか、どっちでエラーになっているのかが分かりづらくなる。
エラーメッセージも1種類にしかできない。

と、急に読みにくくなります。

「ルール1つにつき if 1つ」
これは、小さいアプリでもかなり効くコツです。

エラー表示を少し“やわらかく”してみる

メッセージの質も設計のうち

今のメッセージはちょっと機械的です。

「未入力です。何か入力してください。」
「3文字以上で入力してください。」
「20文字以内で入力してください。」

これでもいいのですが、少しだけやわらかくすることもできます。

if (trimmed === "") {
  return "まだ何も入力されていません。ひとこと書いてみてください。";
}

if (trimmed.length < minLength) {
  return minLength + "文字以上でお願いします。今は " + trimmed.length + " 文字です。";
}

if (trimmed.length > maxLength) {
  return maxLength + "文字以内でお願いします。今は " + trimmed.length + " 文字です。";
}

if (trimmed === "") {
  return "まだ何も入力されていません。ひとこと書いてみてください。";
}

if (trimmed.length < minLength) {
  return minLength + "文字以上でお願いします。今は " + trimmed.length + " 文字です。";
}

if (trimmed.length > maxLength) {
  return maxLength + "文字以内でお願いします。今は " + trimmed.length + " 文字です。";
}

ここで意識しているのは、

「ダメな理由」＋「今どうなっているか」

をセットで伝えることです。

入力チェックは、「怒る」ためではなく「導く」ためにあります。
メッセージの設計も、プログラミングの一部です。

3日目の小さな発展：入力中にエラーを消す

「送信ボタンを押すたびエラーが変わる」だけだとちょっと固い

今のままだと、

送信ボタンを押す → エラーが出る
もう一度送信ボタンを押す → エラーが更新される

という動きです。

ここに、「入力を変えた瞬間にエラーを消す」という振る舞いを追加してみましょう。

input イベントで「修正中」を表現する

input イベントを使って、
文字を入力したらとりあえずエラーを消しておきます。

inputEl.addEventListener("input", handleInputChange);

function handleInputChange() {
  // 入力が変わった＝ユーザーが直そうとしている
  // いったんエラーを消してあげる
  showError("");
}

inputEl.addEventListener("input", handleInputChange);

function handleInputChange() {
  // 入力が変わった＝ユーザーが直そうとしている
  // いったんエラーを消してあげる
  showError("");
}

これだけでも、印象がだいぶ変わります。

エラーが出る。
入力を直し始める。
→ エラーが一旦消える（“今直してるよね”と理解してくれている感じ）。

もちろん「入力中にもリアルタイムで validate をかける」こともできますが、
初級の3日目では「直している間はエラーを一旦引っ込める」くらいで十分です。

「今の設計でルールを増やす想像」をしてみる

例えば「NGワードを含んでいないか」を足すとしたら

たとえば、特定の言葉を禁止にしたいとします。

ここでは例として、「NG」という文字列が含まれていたら弾く、というルールを考えます。

function validate(text) {
  const trimmed = text.trim();

  if (trimmed === "") {
    return "まだ何も入力されていません。ひとこと書いてみてください。";
  }

  if (trimmed.length < minLength) {
    return minLength + "文字以上でお願いします。今は " + trimmed.length + " 文字です。";
  }

  if (trimmed.length > maxLength) {
    return maxLength + "文字以内でお願いします。今は " + trimmed.length + " 文字です。";
  }

  if (trimmed.includes("NG")) {
    return "「NG」という文字列は使えません。別の表現にしてみてください。";
  }

  return "";
}

function validate(text) {
  const trimmed = text.trim();

  if (trimmed === "") {
    return "まだ何も入力されていません。ひとこと書いてみてください。";
  }

  if (trimmed.length < minLength) {
    return minLength + "文字以上でお願いします。今は " + trimmed.length + " 文字です。";
  }

  if (trimmed.length > maxLength) {
    return maxLength + "文字以内でお願いします。今は " + trimmed.length + " 文字です。";
  }

  if (trimmed.includes("NG")) {
    return "「NG」という文字列は使えません。別の表現にしてみてください。";
  }

  return "";
}

ここで注目してほしいのは、

新しいルールを足しても、
他の部分（handleSubmit / showError）には一切触っていない

ということです。

「チェックは validate の責任」という分離が、
ルール追加のときにめちゃくちゃ効いています。

3日目のまとめと、4日目へのつなぎ

今日やったことを整理します。

最小文字数（minLength）を導入して、「短すぎる」ケースもエラーにできるようになった。
空 / 短すぎ / 長すぎ のチェック順を、人間の感覚に合わせて設計した。
「1つのルールに1つの if」というスタイルで、validate を読みやすく保つ感覚をつかんだ。
エラーメッセージを少しやわらかくして、「何がダメで、今どうなのか」を伝える練習をした。
input イベントで「入力中はとりあえずエラーを消す」という小さなUX改善を体験した。
新しいルール（NGワードなど）を足すときに、「validate だけ触ればいい状態」がどれだけ楽かを感じた。

4日目以降は、ここに

入力欄を2つに増やして「項目ごとにエラーを出す」
複数エラーをどう扱うか考える
成功メッセージとエラーメッセージの表示場所を設計する

といった、「フォームっぽさ」を強める方向で進めていきます。

最後にひとつ聞きたい。

今日の中で、「あ、これ自分ちょっと好きかも」と感じたポイントはどこでしたか？
minLength / maxLength で“ちょうどいい長さ”をコントロールするところか、
エラーメッセージをやわらかくするところか、
入力中にエラーが引っ込んでくれる安心感か。

その「好きだな」と感じた部分が、あなたと“入力チェックアプリの設計センス”をつなぐ場所です。
そこを大切にしながら、4日目の“複数項目チェック”に進んでいきましょう。