JavaScript | 1 日 90 分 × 7 日アプリ学習:入力チェックアプリ(初級編)

JavaScript
スポンサーリンク

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

2日目のテーマは「昨日つくった“入力チェック”の流れを、ちゃんとした設計に育てること」です。
機能としてはまだ同じです。

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

ただし今日は、

チェック処理を関数として分離する。
「エラーを返す関数」と「エラーを表示する処理」を分ける。
今どの条件でエラーになっているのか、コードから読み取りやすくする。

ここを意識します。
「同じことを、より“きれいな形”で書き直す日」です。


1日目を一度“設計目線”で振り返る

1日目の handleSubmit の形

昨日の基本形はだいたいこんな感じでした。

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 handleSubmit() {
  const value = inputEl.value;
  const trimmed = value.trim();

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

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

  errorEl.textContent = "";
  alert("入力ありがとうございます!");
}
JavaScript

やっていることは正しいし、シンプルで分かりやすいです。
ただ、よく見ると「handleSubmit の中で全部やっている」状態です。

値を読む。
チェックする。
エラー文言を決める。
エラーを表示する or 成功処理をする。

2日目は、この中の「チェック部分」を関数として切り出していきます。


入力チェックを関数として“ひとつの道具”にする

validate 関数のイメージ

「入力値を渡したら、エラー文言(なければ空文字)を返してくれる関数」を作ります。
名前はよくある validate にしましょう。

function validate(text) {
  // ここでチェックして、エラーがあればそのメッセージを返す
  // 問題なければ ""(空文字)を返す
}
JavaScript

この関数の役割はただ一つです。

「この入力はOKか?ダメなら、何がダメなのか?」

これを“文字列で”答えること。
画面に表示するのは別の役割にします。

validate の中身を組み立てる

昨日の条件をそのまま移植します。

const maxLength = 20;

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

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

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

  return ""; // 問題なし
}
JavaScript

ここでの重要ポイントは3つです。

trim は validate の中でやっている(チェック用の“正規化”)。
ダメな条件ごとに、対応するエラーメッセージを return している。
全部のチェックを通過したら、最後に空文字を返している。

これで、「チェックロジックだけが詰まった関数」ができました。


handleSubmit を「入力→チェック→表示」に整理する

validate を使った handleSubmit の新しい形

validate を使うと、handleSubmit はこう書けます。

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

  const errorMessage = validate(value);

  if (errorMessage !== "") {
    errorEl.textContent = errorMessage;
    return;
  }

  errorEl.textContent = "";
  alert("入力ありがとうございます!");
}
JavaScript

ここでの流れはとてもきれいです。

入力欄から値を取る。
validate に渡してエラーメッセージを受け取る。
エラーメッセージが空でなければ、それを表示して処理をやめる。
空なら OK とみなして、成功処理に進む。

handleSubmit は「フローの管理」だけを担当し、
チェックの中身は validate に任せています。

なぜこの分離が大事なのか

もし今後、「チェック条件を変えたい」「チェックを増やしたい」となったとき、
やるべきことが明確になるからです。

チェックを変えたい → validate だけを触ればいい。
送信時の挙動を変えたい(例:送信後に入力を空にする) → handleSubmit を触ればいい。

役割が分かれていると、「どこをいじるべきか」で迷わなくなります。
この感覚が、“設計できるようになってきたサイン”です。


エラー表示も「小さな関数」にまとめてみる

エラー表示を関数にすると何がうれしいか

エラー表示も、小さな関数にしてしまえます。

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

空文字を渡せば、「エラーを消す」という意味にもできます。

showError("");
JavaScript

これを使って handleSubmit を書き換えてみます。

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

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

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

やっていることは同じですが、
「handleSubmit が“言葉”として読める形」になっています。

入力を取得する。
validate でチェックする。
エラーがあれば showError する。
なければエラーを消して、成功処理へ。

日本語で読めるコードは、あとで自分が見たときの負担が少ないです。


文字数制限を「表示」にも反映させてみる(少し発展)

残り文字数を表示する

今日の範囲内の“ちょっとした強化”として、
「あと何文字入力できるか」を表示する機能を考えてみます。

HTML側に、残り文字数の表示場所を増やします。

<div id="remain-message"></div>

JavaScriptで要素を取得します。

const remainEl = document.getElementById("remain-message");
JavaScript

入力が変わるたびに、「残り文字数」を表示してみます。
input イベントを使います。

inputEl.addEventListener("input", handleInput);

function handleInput() {
  const value = inputEl.value;
  const trimmed = value.trim();
  const remain = maxLength - trimmed.length;

  if (remain >= 0) {
    remainEl.textContent = "あと " + remain + " 文字入力できます。";
  } else {
    remainEl.textContent = "最大文字数を超えています。";
  }
}
JavaScript

ここでのポイントは、

送信ボタンを押す前から、「今どのくらいか」をフィードバックしていること。

ロジックとしては 1日目の範囲を超えませんが、
「入力チェックをリアルタイムでやる感覚」に触れられます。

validate と矛盾しないようにする意識

大事なのは、「validate と handleInput のルールを一致させる」ことです。

maxLength が変わったら、
validate も handleInput も、両方同じ maxLength を参照する。

この「ルールの一元管理」ができていると、
アプリが大きくなっても“破綻しにくい”です。


「エラーの種類が増えても怖くなくする」考え方

もしチェック条件が増えるとしたら?

例えば今後、こんなルールを足したくなるかもしれません。

ひらがなだけOKにしたい。
数字だけOKにしたい。
特定の記号が含まれていたらエラーにしたい。

このとき、2日目の設計をしておくと楽になります。

やることは、validate の中に if を足すだけです。

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

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

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

  if (!/^[0-9]+$/.test(trimmed)) {
    return "数字のみで入力してください。";
  }

  return "";
}
JavaScript

handleSubmit は、一切触る必要がありません。
チェックの追加・変更は「validate の責任」だからです。

条件分岐の“読みやすさ”を意識する

条件が増えてくると、
「どの順番でチェックするか」が大事になってきます。

重要度が高いものを上に。
ユーザーにまず見せたいエラーからチェックする。

例えば、

未入力か?
→ 未入力なら、文字数とか以前の問題なので、先にチェック。

長すぎないか?
→ 長すぎると、その時点で“アウト”なので早めに返す。

中身のルールに合っているか?
→ ここまで通っていれば、「中身の質」をチェック。

というような順番です。

2日目のうちに「順番をどうするか」を意識し始めると、
3日目以降の入力チェックがかなり楽になります。


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

今日やったことを、言葉で整理します。

入力チェックの中身を validate 関数に切り出し、「入力→チェック→結果(エラー文言)」という“道具”にした。
handleSubmit では、「入力を受け取る」「validate に投げる」「エラーがあれば表示する」という流れだけを担当させた。
showError 関数で、エラー表示の処理を1か所にまとめ、「エラーを出す/消す」をわかりやすくした。
文字数制限を使って、残り文字数の表示(リアルタイムのフィードバック)にも触れた。
「チェック条件が増えたときに、どこを直せばいいか」が、validate という1つの場所にまとまる感覚を持てた。

3日目以降は、ここに「チェックの種類」を少しずつ増やしていきます。

数字だけ/ひらがなだけ/メールっぽい形式 など、
現実の入力フォームに近いチェックをしながら、

エラー文言の設計
複数エラーをどう扱うか
どのタイミングでチェックするか(入力中か、送信時か)

といった“入力チェックアプリらしさ”を強めていきます。

最後にひとつだけ訊きたい。

今日の中で、「あ、これちょっとスッキリしたな」と感じたのはどこでしたか?
validate にチェックを集めた瞬間か、handleSubmit が“日本語みたいに読める”形になったときか。

その「スッキリ感」が、あなたの設計センスの芯です。
そこを大事にしながら、3日目のチェック強化に進んでいきましょう。

タイトルとURLをコピーしました