JavaScript | 1 日 120 分 × 7 日アプリ学習：ミニ業務アプリ（総合）

Web APP JavaScript
2026.04.04
スポンサーリンク
スポンサーリンク
  1. 2日目のゴールと今日やること
  2. 画面遷移を「Controller の責務」として扱う
    1. 画面遷移は“画面の仕事”ではなく“アプリの仕事”
  3. AppController を作って“アプリ全体の流れ”を管理する
    1. AppController の役割を言葉で定義する
  4. ログイン画面の流れを“状態遷移”として考える
    1. ログイン成功 → 一覧へ
  5. 一覧 → 詳細 → 編集の流れを“Controller の判断”でつなぐ
    1. 一覧画面で「詳細を見る」ボタンが押されたら？
    2. 詳細画面で「編集する」ボタンが押されたら？
    3. 編集画面で「保存」ボタンが押されたら？
  6. 権限制御を“UI と Controller の両方で”行う理由
    1. UI だけで制御すると危険
    2. Controller 側でも必ずチェックする
  7. 2日目のまとめ：画面遷移は“Controller の責務”
  8. 次のステップ（3日目）でやること
  9. 3日目のゴールと今日のテーマ
  10. UI とロジックをつなぐ“橋”をどう設計するか
    1. 画面ごとにバラバラに書くと何が起きるか
  11. AppController に“UI の入口”を渡す設計
    1. HTML 側のざっくりイメージ
    2. AppController に DOM を注入する
  12. イベントを“Controller の中だけ”に閉じ込める
    1. #setupEvents で UI とロジックを結びつける
  13. 画面の切り替えを“状態遷移”として整理する
    1. どの画面を表示するかを一元管理する
  14. 一覧の描画と「行クリック → 詳細」の流れ
    1. 一覧テーブルを Controller から描画する
  15. 編集の保存と権限制御を“二重で守る”
    1. 保存処理の流れ
  16. 3日目でいちばん深掘りしてほしいこと
  17. 4日目のゴールと今日のテーマ
  18. バリデーションは「画面の都合」ではなく「ドメインのルール」
    1. ありがちな“全部画面に書く”パターン
  19. Customer に「ルール」を閉じ込める設計
    1. バリデーション専用メソッドを持たせる
  20. エラーメッセージは「どこで決めるか」を分けて考える
    1. ルールのメッセージと、UI のメッセージは別物
  21. 「想定外の状態」をどう扱うかも設計の一部
    1. ありえないはずのケースは、本当にありえないか？
  22. 権限制御を「仕様変更に強い形」にする
    1. Permission クラスを“if の墓場”にしない
  23. 「実務思考」とは“未来の自分を楽させる思考”
    1. 今だけ動けばいいコードと、育てられるコード
  24. 4日目の締め：if 文の“居場所”を意識する
  25. 5日目のゴールと今日のテーマ
  26. 「仕様変更が来た」と仮定して設計をチェックする
    1. 想定する変更 1：ログイン方法が変わる
  27. Auth を「認証の窓口」として育てる
    1. 認証方法を増やせる形にしておく
  28. 「一覧の仕様変更」に耐えられる設計かをチェックする
    1. 想定する変更 2：一覧にフィルタとソートを追加したい
  29. 一覧のフィルタとソートを Controller から使う
    1. Controller 側の責務を整理する
  30. 「権限の仕様変更」に耐えられる設計かをチェックする
    1. 想定する変更 3：権限ルールが細かくなる
  31. 実務思考：テストしやすい設計になっているか？
    1. 「ブラウザを開かなくても確認できる部分」を増やす
  32. 5日目でいちばん深く持ってほしい感覚
  33. 6日目のゴールと今日のテーマ
  34. 「Controller が太り始めた」ときにどう見るか
    1. AppController は太りやすいクラス
  35. 画面ごとに「小さな View クラス」を切り出す
    1. 役割を言葉で分けてみる
  36. LoginView を切り出してみる
    1. UI 専用の小さなクラス
  37. ListView も同じ発想で切り出す
    1. 一覧画面の UI をまとめる
  38. 「View を切り出す」ことの実務的メリット
    1. 画面デザイン変更が怖くなくなる
  39. 「Controller がやるべきこと」をもう一度言語化する
    1. Controller の責任は“判断と調整”だけにする
  40. 6日目でいちばん深く持ってほしい感覚
  41. 7日目のゴールと視点の切り替え
  42. いま作っているアプリを「レイヤー」で言い直す
    1. ドメイン層を言葉で説明できるか
    2. アプリケーション層と UI 層を整理して言う
  43. 設計力を“判断基準”として言語化する
    1. 「この処理はどのクラスの責任か？」を即答できるか
  44. 保守性を“変更シミュレーション”で確かめる
    1. 仕様変更を仮定して「どこを直すか」を言ってみる
  45. 実務思考を“自分のルール”として持ち帰る
    1. 「現場で本当に役立つ視点」を3つに絞る
  46. 7日目の締め：あなたの言葉でまとめてみてほしいこと

2日目のゴールと今日やること

2日目のテーマは
「画面（UI）とロジック（ドメイン）をつなぐ“アプリの流れ”を設計すること」です。

昨日は
User / Auth / Customer / CustomerRepository / Permission
という“役割ベースのクラス設計”を学びました。

今日はそこに、

  • ログイン画面の流れ
  • 一覧 → 詳細 → 編集の画面遷移
  • 権限による UI の出し分け（擬似）

を組み合わせて、
「業務アプリらしい動き」を設計できるようにします。

まだ本格的な DOM コードは書きません。
今日は “画面の流れをクラスでどう表現するか” に集中します。

前へ
12
スポンサーリンク
タイトルとURLをコピーしました