驗證姓名與 Email
修改檔案:script.js
完成後看見:畫面顯示姓名、Email 驗證結果,通過時仍明確標示尚未建立 payload
CHAPTER 23 · PRACTICE WORKSPACE
完成可驗證、提交並顯示結果的聯絡表單
TASK STATUS
修改檔案:script.js
完成後看見:畫面顯示姓名、Email 驗證結果,通過時仍明確標示尚未建立 payload
修改檔案:script.js
完成後看見:預覽區顯示 name、email、message,狀態為「payload 已建立;尚未送出」
修改檔案:script.js
完成後看見:成功與失敗都可重現,送出期間按鈕停用且完成後恢復
WORKSPACE
先確認作品目前能做什麼、還缺什麼,再從 TASK-01 開始修改。
FOCUS TASK · TASK-01
比較:驗證只判斷輸入是否可接受,payload 是送出前的資料物件;兩者要清楚分段。
現在做:在 Checkpoint 1 先保持姓名空白、Email 輸入 a 後送出;再填姓名「小安」但保留錯誤 Email;最後填入 xiaoan@example.com 與訊息後送出。每一步都記錄 status 與 payload-preview,不要先修改 createPayload()。
預期:三次結果依序是「請輸入姓名」、「Email 格式不正確」與「驗證通過;尚未建立 payload」;三次都沒有建立 payload。
證據:留下三列紀錄:輸入值、status、payload-preview,證明 validate() 先於 payload 建立,而且不同錯誤對應不同訊息。
比較:姓名與 Email 的不同錯誤狀態應各自顯示,不能只測一筆正確資料。
現在做:重跑三種輸入:空白姓名、錯誤 Email、完整資料;每次送出前先預測 status 與 preview,送出後核對實際文字,並確認錯誤路線不會清掉輸入。
預期:姓名錯誤與 Email 錯誤各自可辨識;只有完整資料顯示驗證通過,且 payload-preview 仍維持「尚未建立 payload」。
證據:用三組輸入/預測/實際結果表,證明不是只測一筆正確資料,也沒有把錯誤統一成「提交失敗」。
完成條件:DONE-01:畫面顯示姓名、Email 驗證結果,通過時仍明確標示尚未建立 payload
MOCK POST
尚未建立 payload
CONTINUE
前往 Checkpoint 1,依要求完成「驗證姓名與 Email」。
CHAPTER HANDOFF
接收第 22 章:沿用已完成的產品列表與分頁邊界證據;本章不重做列表,改處理使用者輸入、驗證與提交生命週期。
交給第 24 章:完成後帶著驗證通過的 payload、loading/success/error 與 finally 恢復證據,下一章直接比較一次 POST 與持續訂閱,不重做表單驗證。
前往第 24 章:即時資料模型與 Firebase 介面