擋住錯誤資料
姓名空白或 Email 不合法時，顯示原因且不送出。
CHAPTER 23 · 180 MINUTES
表單驗證、POST 與資料寫入
表單像寄件櫃台：先驗收內容、整理 payload、送出一次，最後把成功或失敗清楚交代。
3個明確任務
4種提交狀態
1次有效送出
LEARNING GOALS
本章結束時，你能做出什麼
整理 POST payload
送出前能預覽固定欄位的 JSON，不直接丟整個表單。
管理完整流程
送出期間停用按鈕，成功或失敗後都恢復可操作。
PROBLEM & ANALOGY
按下送出，不等於資料已安全到達
第 22 章都在讀取資料；本章第一次接住使用者輸入。validation 像櫃台驗件、payload 像寄件單、POST 像交寄、loading 像處理中號碼牌。
本章要解決：錯誤內容不能送出，連點不能製造重複請求，失敗後介面也不能鎖死。
合回共同作品：聯絡表單會成為作品集能被別人實際操作的入口。
把名詞對回畫面與程式
- preventDefault
- 阻止瀏覽器直接換頁，讓程式先完成驗證。
- validate
- 送出前檢查姓名、Email 是否符合規則。
- payload
- 準備送到服務端的固定欄位資料。
- POST
- 把資料送往服務端的方法，需符合契約。
- finally
- 成功或失敗都會執行，適合恢復按鈕與 loading。
SCOPE
今天的學習邊界
能自己完成
validation、payload、POST、loading／success／error 與 finally 收尾。
看得懂即可
HTTP method、request body 與 content type 是送出契約的一部分。
刻意延後
檔案上傳、OAuth、正式防垃圾機制與敏感個資收集。
CORE IDEAS
送出前、中、後都有責任
- 先
preventDefault()，讀取欄位後執行 validate；不合法就停止。 createPayload()只建立允許送出的固定欄位，預覽後才 POST。- 送出期間鎖定按鈕，避免同一份資料被連點送出。
- 成功與失敗都要進入可理解狀態，並在 finally 恢復按鈕。
- 標準練習使用 mockSubmit；只有 Network 與後端證據才能宣稱真實寫入。
DEBUGGING
依提交生命週期逐站檢查
課堂刻意錯誤：連點造成重複送出，或只在 success 恢復按鈕，讓 error 後介面永久鎖死。
- 確認 submit 事件只綁一次，錯誤資料沒有進入 request。
- 檢查 validate 結果與 payload preview 是否一致。
- 到 Network／mock log 確認請求次數、method 與 body。
- 確認 loading、success、error 都有可見狀態。
- 重跑失敗路線，確認按鈕會恢復且敏感資料沒有印進 Console。
錯誤 Email 仍送出
先查：確認 preventDefault、validate 與請求呼叫順序。
payload 多了欄位
先查：對照 payload 預覽與允許欄位，不送整個表單物件。
失敗後按鈕鎖住
先查：確認 finally 在 success 與 error 後恢復提交狀態。
PRACTICE CONTRACT
Starter 到 Solution 共用同一張聯絡表單
開始前先確認這四件事
- 我先測空白、錯誤 Email 與正常資料。
- 我知道驗證通過前不會送出 request。
- payload 只包含允許欄位。
- 我會測試連點與 mock 失敗後恢復。
驗證姓名與 Email
檔案：script.js
位置：validate()
結果：空白或不合法 Email 不會送出
建立明確 POST payload
檔案：script.js
位置：createPayload()
結果：預覽區顯示即將送出的 JSON
送出並管理 loading/success/error
檔案：script.js
位置：mockSubmit()、handleSubmit()
結果：成功與失敗都可重現，送出期間按鈕停用且完成後恢復
EVIDENCE
成果證據與檢核
30 秒說法可以直接照這個句型練習：
送出先由 ______ 驗證；payload 只有 ______；失敗後由 ______ 恢復 ______。
使用 mockSubmit 時要清楚寫「模擬」；不要把 mock 寫入說成正式後端資料。
展示空白、錯誤 Email、成功與模擬失敗四條路線；附一次 payload 預覽，以及送出期間按鈕停用的畫面。
下一章：從一次 POST 改成持續訂閱即時資料。