10-3. 演習問題

問題1：選択問題

1-1. 入力チェックの主な目的として最も適切なのはどれか。

A. 画面の色を変えるため
B. 壊れたデータを state に入れないため
C. render() を不要にするため

解答と解説

正解：B. 壊れたデータを state に入れないため

B が正しい。入力チェックは見た目の問題ではなく、内部状態を壊さないための処理である。
A は誤り。UI の色変更とは目的が違う。
C は誤り。検証しても、表示を更新する render() は必要である。

1-2. 一覧の 1 冊だけ状態を更新したいとき、意図に最も合う配列メソッドはどれか。

A. map()
B. join()
C. includes()

解答と解説

正解：A. map()

A が正しい。map() は各要素を見ながら、新しい配列を作り直せる。
B は誤り。文字列連結用であり、要素更新には向かない。
C は誤り。含まれているか調べる関数であり、更新には使わない。

1-3. 一覧から指定した 1 冊を取り除きたいとき、最も適切なのはどれか。

A. filter()
B. forEach()
C. trim()

解答と解説

正解：A. filter()

A が正しい。残したい要素だけを集めて、新しい配列を作り直せる。
B は誤り。反復処理であり、戻り値として新しい配列を作る用途ではない。
C は誤り。文字列の前後空白を除く関数である。

1-4. 入力エラーが見つかった直後にまず行うべきこととして最も適切なのはどれか。

A. state.errorMessage を更新して render() を呼ぶ
B. そのまま books.unshift(...) する
C. 何もせずに次の入力を待つ

解答と解説

正解：A. state.errorMessage を更新して render() を呼ぶ

A が正しい。エラー内容を画面へ反映する必要がある。
B は誤り。不正入力でも追加されてしまう。
C は誤り。ユーザーに何が悪いか伝わらない。

1-5. 一覧の各ボタンを毎回作り直す画面で、親要素に click を 1 つ置く利点として最も適切なのはどれか。

A. 再描画後も同じロジックを使いやすい
B. render() を削除できる
C. 配列が自動で保存される

解答と解説

正解：A. 再描画後も同じロジックを使いやすい

A が正しい。イベント委譲は再描画に強い。
B は誤り。再描画関数そのものは必要である。
C は誤り。保存処理とは無関係である。

問題2：穴埋め問題

壊れた入力を保存前に止める処理を （　　　） という。
一覧の 1 件だけ中身を変えて新しい配列を作るときによく使うのは Array.**（　　　）**() である。
残したい要素だけを集めて削除後の配列を作るときによく使うのは Array.**（　　　）**() である。
画面へ現在の state を写し直す関数は （　　　） のような名前にすると分かりやすい。
フォーム全体に対するエラー文言を持つ state の例は error**（　　　）** である。

解答欄

解答と解説

入力チェック
map
filter
render
Message

入力チェックは state を壊さないための入口である。map() は更新、filter() は削除、render() は再描画という役割で整理すると混乱しにくい。

問題3：記述問題

3-1. なぜ入力チェックは「見た目の都合」ではなく「state を守る処理」と考えたほうがよいのか説明してください。

解答欄

解答と解説

空欄タイトルや不正な価格をそのまま state に入れると、一覧表示・件数表示・後続の更新処理がすべて不安定になる。入力チェックは UI を厳しくするためではなく、後続の処理が前提とするデータ形を守るために必要である。

3-2. 状態変更で map()、削除で filter() を使い分ける理由を説明してください。

解答欄

解答と解説

状態変更は「要素は残したまま一部の中身だけ変える」処理なので map() が合う。削除は「残す要素だけを集め直す」処理なので filter() が合う。目的に応じて配列操作を分けると、コードの意図が読みやすい。

3-3. なぜ render() を追加・更新・削除のたびに共通で呼ぶ設計がよいのか説明してください。

解答欄

解答と解説

件数表示・エラー表示・一覧表示を別々に手で直すと、どれか 1 つだけ更新漏れする危険がある。render() に表示更新を集めると、state を変えたあとに 1 つの入口で画面をそろえられるため、表示のずれを防ぎやすい。

問題4：ハンズオン

プレイグラウンドで、入力チェック・状態変更・削除の流れを確認してみましょう。

このプレイグラウンドは DOM を使わず、関数を直接呼び出して console.log で結果を観察します。
TODO を 1 つ埋めるたびに実行し、どの段階で出力が変わったかを順番に確認してください。

実行プレイグラウンド

編集内容は自動保存されます / Ctrl+Enter でも実行できます

const state = {
books: [
  { id: "b1", title: "JavaScript入門", author: "山田太郎", category: "フロントエンド", price: 2800, status: "未読", memo: "まず DOM を理解する" },
],
errorMessage: "",
};

function validateBook(book) {
const errors = [];
// TODO 1: title が空 / author が空 / price が 0 以下のとき errors に文言を push する
return errors;
}

function nextStatus(currentStatus) {
const statuses = ["未読", "読書中", "読了"];
return statuses[(statuses.indexOf(currentStatus) + 1) % statuses.length];
}

function render() {
// TODO 2: state の件数・エラー・各本のタイトルと状態を console.log する
// 例: console.log("登録冊数:", state.books.length, "| エラー:", state.errorMessage || "なし");
//     state.books.forEach(b => console.log(" -", b.title, b.status));
}

// === TODO 1 の確認 ===
console.log("--- validateBook ---");
const goodBook = { id: "b2", title: "CSS設計入門", author: "研修花子", category: "設計", price: 3500, status: "未読", memo: "" };
const badBook  = { title: "", author: "", category: "", price: 0, status: "未読", memo: "" };
console.log("正常:", validateBook(goodBook));   // [] が期待値
console.log("エラー:", validateBook(badBook)); // エラー文言の配列が期待値

// === TODO 2 の確認 ===
console.log("--- render（初期）---");
render();

// === TODO 3: エラー時と成功時の追加を確認する ===
console.log("--- TODO 3: 追加 ---");
// TODO 3a: badBook を validateBook して errors.length > 0 なら state.errorMessage に入れて render()
// TODO 3b: goodBook を validateBook してエラーなしなら先頭へ追加し errorMessage をリセットして render()

// === TODO 4: 状態変更と削除を確認する ===
console.log("--- TODO 4: 状態変更 & 削除 ---");
// TODO 4a: state.books を map() で作り直し id "b1" の本だけ nextStatus() で状態を変えて render()
// TODO 4b: state.books を filter() で id "b1" でない本だけ残して render()

console.log("TODO 1〜4 を埋めたら実行して出力を確認しよう");

出力

「実行」を押すと、ここに結果が表示されます。

手順

TODO 1 を埋めて実行し、正常データでは []、不正データではエラー文言の配列が出ることを確認する
TODO 2 を埋めて実行し、render() が件数・エラー・一覧をコンソールに出すことを確認する
TODO 3 を埋めて実行し、エラー時は件数が増えずエラー文言が出て、正常時は件数が増えてエラーが消えることを確認する
TODO 4 を埋めて実行し、状態変更では対象本の status だけが変わり、削除後は件数が減ることを確認する

期待する出力例

--- validateBook ---
正常: []
エラー: [ タイトルは必須です, 著者は必須です, 価格は1以上の整数で入力してください ]
--- render（初期）---
登録冊数: 1 | エラー: なし
 - JavaScript入門 未読
--- TODO 3: 追加 ---
登録冊数: 1 | エラー: タイトルは必須です
 - JavaScript入門 未読
登録冊数: 2 | エラー: なし
 - CSS設計入門 未読
 - JavaScript入門 未読
--- TODO 4: 状態変更 & 削除 ---
登録冊数: 2 | エラー: なし
 - CSS設計入門 未読
 - JavaScript入門 読書中
登録冊数: 1 | エラー: なし
 - CSS設計入門 未読
TODO 1〜4 を埋めたら実行して出力を確認しよう

解答と解説

TODO 1 の考え方

validateBook() は「追加してよいか」を判断する入口である。タイトル・著者・価格のうち、後続処理が前提とする条件だけを先に守る。エラーが複数あっても扱えるよう配列で返す点が重要である。

TODO 2 の考え方

render() は「今の state を丸ごとコンソールへ写す」関数と考える。件数・エラー・一覧タイトルを 1 箇所で出力する形にしておくと、TODO 3・4 の変化を確認しやすい。

TODO 3 の考え方

エラーがある場合は state.errorMessage を更新して render() を呼び、return で止める。エラーがない場合は errorMessage を空にリセットし、state.books.unshift(...) で先頭へ追加してから render() を呼ぶ。

TODO 4 の考え方

状態変更: map() で 1 件だけ status を変える
削除: filter() でその本以外を残す

どちらも render() を呼ぶことで、件数と一覧が常にそろう。