看懂訂閱生命週期
主畫面與第二 Console subscriber 都能接住 snapshot，並且可獨立 unsubscribe。
CHAPTER 24 · 240 MINUTES
即時資料模型與 Firebase 介面
本章共 240 分鐘：課次 24 用 memory adapter 建立即時資料模型，課次 25 前 60 分鐘追蹤 adapter、模擬訂閱失敗與復原；全程不冒充真 Firebase。
1個標準 adapter
3個明確任務
0次 innerHTML
LEARNING GOALS
本章結束時，你能做出什麼
用 trace 找重複 listener
實際看到 subscribe、notify、push 與 unsubscribe 順序，不再靠猜。
從訂閱失敗復原
失敗時保留舊留言且不留幽靈 listener，retry 後回到正常更新。
進場檢核與作品接力
- 具備第 23 章成果：完成可驗證、提交並顯示結果的聯絡表單：不看答案，展示或口述第 23 章成果，並說出一項可見證據。 需要補強時從這裡接回
- 能從 Starter、Checkpoint 與 Solution 中辨識目前工作階段：開啟本章主講義，指出 TASK-01 的修改檔案、可見結果與第一個 Checkpoint。 需要補強時從這裡接回
- 能用「操作後看見什麼」描述驗收證據：閱讀三個任務後，選一題說出操作條件與預期可見結果。 需要補強時從這裡接回
輸入：第 23 章產物：完成可驗證、提交並顯示結果的聯絡表單
本章輸出：完成可追蹤、可取消、可模擬訂閱失敗並重試的 memory adapter 即時留言原型，不冒充 Firebase
產物類型：prototype；後續用途：第 25 章
PROBLEM & ANALOGY
即時不是一直重新整理
第 23 章是寄出一次後等結果；本章像訂閱共同白板，資料來源一變就通知所有同一個 adapter 的 subscriber。
本章要解決：訂閱可能重複、snapshot 可能為空、留言可能含惡意標籤；每一層都要有明確責任。
名稱邊界：標準 solution 使用 memory adapter 練習 Firebase 介面責任，不是原生 WebSocket 教學，也不冒充已連線 Firebase。
把名詞對回畫面與程式
- subscribe
- 建立資料更新監聽，通常先收到初始 snapshot。
- snapshot
- 某一時間點的資料快照，可能是空值、陣列或物件。
- push
- 把新留言寫入 adapter 或資料來源。
- unsubscribe
- 取消舊 listener，避免重複訂閱與幽靈回呼。
- textContent
- 以純文字建立留言，避免輸入當成 HTML 執行。
SCOPE
今天的學習邊界
能自己完成
ref、onValue、snapshot、push、unsubscribe 與安全 DOM 渲染。
看得懂即可
Firebase Web app config、Realtime Database 與最小權限 Rules。
刻意延後
原生 WebSocket 協定、正式 Rules 架構與大規模資料查詢。
Live Extension（選修）：Firebase Realtime 正式環境操作與 Network 證據不影響 Mock 必修主線。開啟安全操作手冊
CORE IDEAS
同一份介面，分開標準練習與 Live 延伸
- subscribe 會先送初始資料；回傳的函式用來取消舊 listener，避免重複。
- push 只改資料來源，畫面由 subscriber 收到 snapshot 後統一 render。
- 標準驗收只在同一個 solution 頁面、同一個 memory adapter 建立第二個 Console subscriber。
- 兩個分頁各有獨立 JavaScript context 與 memory adapter，本來就不會同步。
- 真 Firebase 雙視窗延伸必須連到同一 database 與 path，並準備 Emulator 或最小權限 Rules。
DEBUGGING & SECURITY
監聽數、資料筆數與 DOM 都要檢查
課堂刻意錯誤：重複 subscribe 未取消；或 addMessage 先 append、callback 又 render；再輸入 <img src=x onerror=alert(1)> 驗證 XSS。
- 確認 adapter 模式、ref path 與 listener 數量。
- 檢查 snapshot 是空值、陣列還是物件，再看實際筆數。
- 確認 push 只執行一次，畫面只由 render 更新。
- 留言節點必須由
createElement()、textContent建立；任何 innerHTML 直接退件。 - Live 延伸再查 config、Rules、Network 與兩個視窗是否連到同一路徑。
資料更新兩次
先查：看 trace 與 listener 數量，確認舊 subscriber 有 unsubscribe。
輸入標籤造成風險
先查：檢查留言節點用 createElement 與 textContent，禁止 innerHTML。
retry 後留言消失
先查：確認失敗保留舊資料，恢復後由 snapshot 重畫。
PRACTICE CONTRACT
四階段共用同一份可追蹤 memory adapter 骨架
開始前先確認這四件事
- 我知道標準 solution 使用 memory adapter。
- 我能說出 subscribe、push、snapshot、unsubscribe 順序。
- 我會測試第二個 Console subscriber 的取消。
- 我會輸入 XSS 字串並檢查純文字。
訂閱主畫面並留下 adapter trace
檔案：script.js
位置：依任務文字搜尋對應元素或函式
結果：主畫面 subscriber 收到初始 snapshot，trace 顯示 subscribe 與 notify
安全渲染並管理第二 Console subscriber
檔案：script.js
位置：依任務文字搜尋對應元素或函式
結果：留言以純文字渲染，Console subscriber 可訂閱並可 unsubscribe
模擬訂閱失敗、復原重試並新增留言
檔案：script.js
位置：依任務文字搜尋對應元素或函式
結果：失敗時保留舊留言且無幽靈 listener，retry 後畫面與 Console subscriber 同時收到新 snapshot
EVIDENCE
標準證據與 Live 延伸邊界
30 秒說法可以直接照這個句型練習：
主畫面由 ______ 訂閱；更新經過 ______；取消時呼叫 ______；留言用 ______ 防止 HTML。
標準證據只證明 adapter 介面責任；真 Firebase 需另有 database、Rules 與 Network 證據。
標準證據：同一頁的主畫面與 Console subscriber 都收到更新；取消 Console 後只剩畫面收到。主畫面訂閱失敗時留言不消失，trace 證明沒有幽靈 listener，retry 後才恢復新增。這些只證明 memory adapter 介面。
Live 延伸另驗：Firebase 帳號、project、Web app config、Realtime Database、Rules／Emulator、Network 與同一路徑雙視窗證據。
下一章：加入「現在是誰」與 owner uid 權限判斷。