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 "";
}
JavaScripthandleSubmit は、一切触る必要がありません。
チェックの追加・変更は「validate の責任」だからです。
条件分岐の“読みやすさ”を意識する
条件が増えてくると、
「どの順番でチェックするか」が大事になってきます。
重要度が高いものを上に。
ユーザーにまず見せたいエラーからチェックする。
例えば、
未入力か?
→ 未入力なら、文字数とか以前の問題なので、先にチェック。
長すぎないか?
→ 長すぎると、その時点で“アウト”なので早めに返す。
中身のルールに合っているか?
→ ここまで通っていれば、「中身の質」をチェック。
というような順番です。
2日目のうちに「順番をどうするか」を意識し始めると、
3日目以降の入力チェックがかなり楽になります。
2日目のまとめと、3日目へのつなぎ
今日やったことを、言葉で整理します。
入力チェックの中身を validate 関数に切り出し、「入力→チェック→結果(エラー文言)」という“道具”にした。
handleSubmit では、「入力を受け取る」「validate に投げる」「エラーがあれば表示する」という流れだけを担当させた。
showError 関数で、エラー表示の処理を1か所にまとめ、「エラーを出す/消す」をわかりやすくした。
文字数制限を使って、残り文字数の表示(リアルタイムのフィードバック)にも触れた。
「チェック条件が増えたときに、どこを直せばいいか」が、validate という1つの場所にまとまる感覚を持てた。
3日目以降は、ここに「チェックの種類」を少しずつ増やしていきます。
数字だけ/ひらがなだけ/メールっぽい形式 など、
現実の入力フォームに近いチェックをしながら、
エラー文言の設計
複数エラーをどう扱うか
どのタイミングでチェックするか(入力中か、送信時か)
といった“入力チェックアプリらしさ”を強めていきます。
最後にひとつだけ訊きたい。
今日の中で、「あ、これちょっとスッキリしたな」と感じたのはどこでしたか?
validate にチェックを集めた瞬間か、handleSubmit が“日本語みたいに読める”形になったときか。
その「スッキリ感」が、あなたの設計センスの芯です。
そこを大事にしながら、3日目のチェック強化に進んでいきましょう。

