即時資料模型與 Firebase 介面

第 23 章是寄出一次後等結果；本章像訂閱共同白板，資料來源一變就通知所有同一個 adapter 的 subscriber。

本章要解決：訂閱可能重複、snapshot 可能為空、留言可能含惡意標籤；每一層都要有明確責任。

名稱邊界：標準 solution 使用 memory adapter 練習 Firebase 介面責任，不是原生 WebSocket 教學，也不冒充已連線 Firebase。

1. subscribe 會先送初始資料；回傳的函式用來取消舊 listener，避免重複。
2. push 只改資料來源，畫面由 subscriber 收到 snapshot 後統一 render。
3. 標準驗收只在同一個 solution 頁面、同一個 memory adapter 建立第二個 Console subscriber。
4. 兩個分頁各有獨立 JavaScript context 與 memory adapter，本來就不會同步。
5. 真 Firebase 雙視窗延伸必須連到同一 database 與 path，並準備 Emulator 或最小權限 Rules。

課堂刻意錯誤：重複 subscribe 未取消；或 addMessage 先 append、callback 又 render；再輸入 <img src=x onerror=alert(1)> 驗證 XSS。

1. 確認 adapter 模式、ref path 與 listener 數量。
2. 檢查 snapshot 是空值、陣列還是物件，再看實際筆數。
3. 確認 push 只執行一次，畫面只由 render 更新。
4. 留言節點必須由 createElement()、textContent 建立；任何 innerHTML 直接退件。
5. Live 延伸再查 config、Rules、Network 與兩個視窗是否連到同一路徑。

1. 01 先讀任務 Starter adapter 與函式骨架。 累積完成 0／3 個任務 開始練習 →
2. 02 完成第一項 Checkpoint 1 完成 TASK-01。 累積完成 1／3 個任務 繼續第一步 →
3. 03 累積第二項 Checkpoint 2 再完成 TASK-02。 累積完成 2／3 個任務 繼續第二步 →
4. 04 核對完成品 Solution 完成訂閱失敗、recovery/retry 與新增驗收。 累積完成 3／3 個任務 查看完整結果 →

✓網頁版答案位置對照卡住時先完成 Checkpoint 2，再查看每個 TASK 對應的檔案與位置。→

標準證據：同一頁的主畫面與 Console subscriber 都收到更新；取消 Console 後只剩畫面收到。主畫面訂閱失敗時留言不消失，trace 證明沒有幽靈 listener，retry 後才恢復新增。這些只證明 memory adapter 介面。

• 01 trace 可完整說明 subscribe、notify、push 與 unsubscribe 順序。 已完成
• 02 第二 Console subscriber 可開啟與取消，訂閱數不虛增。 已完成
• 03 模擬失敗保留舊留言，retry 後回到正常訂閱。 已完成
• 04 XSS 測試字串只顯示純文字。 已完成
• 05 沒有把 memory adapter 宣稱成 Firebase。 已完成

Live 延伸另驗：Firebase 帳號、project、Web app config、Realtime Database、Rules／Emulator、Network 與同一路徑雙視窗證據。

下一章：加入「現在是誰」與 owner uid 權限判斷。

下一步：前往第 25 章「身份、uid 與權限模型（概念模擬）」，帶著本章輸出繼續累積作品。