昨天，我們終於把 Hash Window 搞定了。
現在學生端每 30 秒就會檢查一次廣播有沒有更新，而且不需要每次都把所有資料重新抓回來。
從資料庫、權限、確認、回覆，到增量同步，整套系統似乎終於有點樣子了。
所以現在可以用了？
應該吧。
那老師要怎麼發廣播？
POST /broadcasts 啊。
……
我是說，老師要怎麼發廣播？
……
好問題。
總不能叫老師打開 Postman，填好 JSON，再自己帶著 Cookie 去呼叫 API 吧？
也不是不行？
你去跟老師講。
我不要。
我也不要。
先不說會不會被打，老師聽不聽得懂都是問題 hhh。
看來我們又找到一個還沒做完的東西了。
一開始，我其實想直接在現有的廣播頁面加一個「發布廣播」按鈕。
畢竟學生端的廣播列表都做好了，老師應該也能用吧？
但仔細想想，好像哪裡怪怪的。
學生使用數位校園，是為了接收資訊；老師使用數位校園，則主要是為了發布與管理資訊。
兩者的使用動機根本不一樣。
對學生來說，最重要的是快速知道今天有哪些事情、哪些廣播還沒確認。
但對老師來說，他可能更在意：
如果硬要讓老師跟學生共用同一套操作流程，最後可能只是把兩種不同的需求塞進同一個畫面。
所以？
所以這次我們決定把教師端獨立出來。
至少先有兩個主要入口：
「發布廣播」與「我發布的廣播」。
至於學生端原本的介面，就先不要動它。
畢竟那個才剛做好。
你是不是很怕又要重寫？
你不要講出來。
既然要做發布頁面，第一個問題就是選擇接收對象。
我們的廣播不是發給某個學生，而是發給一個或多個班級。
所以這次採用「年級 → 班級」的巢狀選擇器。
老師可以展開年級、勾選班級，也可以直接選取整個年級。
如果要跨年級發布，也不需要重複操作好幾次。
另外，考慮到班級可能不少，我們也加入搜尋。
但這裡有個小細節：
搜尋不能把老師已經選好的班級清掉。
不然老師先選了三年級的幾個班，再搜尋二年級，結果前面選的全部消失……
那應該會很想把電腦砸掉。
對。
所以選取狀態必須獨立於搜尋與展開狀態。
手機版也維持巢狀展開的方式，而不是把所有班級直接攤成一張長到看不完的清單。
至於實際班級資料，當然得從後端取得。
總不能把 399 班硬編碼進去，然後明年大家升級，整個系統就壞掉。
聽起來像你真的會做的事。
……不要亂講。
接下來是廣播內容。
如果只是用一個普通的 <textarea>，其實也不是不能用。
但老師發布的內容有時候需要標題、條列、重點提示，甚至超連結。
如果全部只能用純文字，閱讀起來可能不太舒服。
所以這次決定採用 WYSIWYG 編輯器。
也就是所見即所得。
老師不需要知道什麼是 Markdown，更不用自己寫 HTML，就能直接調整文字格式。
第一版預計支援標題、粗體、斜體、清單與超連結。
至於圖片和附件……
先不做。
等等。
你這樣不是比原本的數位校園還難用嗎？
……
人家原本至少還能處理附件，你重寫了 25 天，結果功能反而變少？
咳。
這個嘛，主要是鐵人賽的時程問題。
畢竟只剩五天了。
所以？
所以先把核心功能做完，剩下的之後再補。
翻譯：做不完。
是範圍管理！
好喔。
不過，蘇同學說得也沒錯。
對真正使用系統的老師而言，功能做不出來就是做不出來，不會因為開發者只剩五天就比較好用。
時程限制可以解釋為什麼做出這樣的取捨，但不能拿來證明這個取捨對使用者比較好。
所以附件功能不是不重要，而是這次先把它排除在實作範圍之外。
另外，富文字編輯器還有一個不能忽略的問題。
XSS。
還記得我們最初決定重寫舊系統的原因嗎？
如果這次為了讓老師能調整字體，就直接把使用者輸入的 HTML 塞進頁面，那我們大概真的可以收工了。
為什麼？
因為我們成功把舊系統的問題重新寫了一遍。
所以編輯器輸出的內容必須受到限制，後端也不能直接信任使用者提交的 HTML。
而且學生端必須能安全顯示這些格式，同時保留對舊純文字廣播的相容性。
這部分就交給實作時仔細處理。
還有一個問題。
我們先前已經決定，廣播發布後不能編輯。
既然如此，老師如果選錯班級，事情就有點麻煩了。
所以這次不打算讓「發布」按鈕一按就直接送出。
老師完成編輯後，系統會先開啟確認視窗。
裡面顯示完整的廣播預覽、所有目標班級，以及發布後不可編輯的提醒。
老師確認沒問題，才真正呼叫 API。
那如果老師連確認視窗都沒看就按下去呢？
……
蝦阿。
那可能不是一個確認視窗能解決的問題。
不過至少我們提供了一次檢查機會。
而且送出期間也得防止重複點擊。
畢竟如果網路卡了一下，老師以為沒成功，又按了一次，結果學生收到兩則一模一樣的廣播……
那就不是廣播了。
那是洗版。
廣播成功送出後，我們不讓老師留在空白的編輯器，也不直接跳進單一廣播的詳情頁。
而是導向「我發布的廣播」。
剛剛發布的那則會被標註出來，讓老師能立刻確認它確實出現在列表裡。
而這個頁面最重要的功能，就是追蹤各班的確認情況。
例如一則廣播發給 12 個班級，其中 8 班已經確認，就顯示：
已確認 8 / 12 班
下面再放一條進度條。
如果老師想知道是哪四班還沒確認，就可以展開查看各班的詳細狀態。
這裡也要記得我們之前訂好的規則：
確認是以「廣播 × 班級」為單位。
而且準時確認與逾期補確認都算已確認，但不能因此把兩種狀態混為一談。
畢竟老師想知道的可能不只是有沒有確認，還包括有沒有準時確認。
總之，這次的需求大致收斂了。
教師端有自己的發布與管理流程，學生端則維持原本的接收、確認與回覆功能。
兩邊雖然操作方式不同，但使用的仍然是同一套廣播資料與權限規則。
接下來，我把這些需求整理成 Agent Task，交給 Agent 檢查現有的 API、資料模型與 Angular 元件，再進行實作和測試。
這次除了介面，還得注意富文字安全、班級權限、重複發布，以及新廣播能否正常進入昨天才完成的 Hash Window。
至於實際成果如何，就等 Agent 跑完再說。
所以今天又是你負責想，Agent 負責寫？
什麼叫「又」？
那你負責什麼？
我負責確保它不要把系統寫壞。
聽起來很重要。
對吧？
尤其是你自己設計的系統。
……
你今天話有點多喔。
iThome鐵人賽
看影片追技術