儀表板更新時，如何不打斷使用者正在閱讀的內容？

資料型 Web 介面有一個容易被忽略的問題：背景更新如果處理不當，可能會打斷使用者正在閱讀的內容。

我目前正在開發一個 XAUUSD 黃金資料儀表板，串接 MT5、MQL5、Windows Server VPS、Python、WordPress REST API 與前端 JavaScript。這次想分享的不是交易策略，而是如何在取得新資料時，保留使用者當下的操作狀態。

專案頁面：<copi-tools.com/zh-ha...>

我想保留的不只是資料

當使用者打開圖表時，通常已經做了一些操作：

• 選擇了特定的時間週期

• 放大或縮小圖表

• 捲動到某一段歷史 K 線

• 正在閱讀某個新聞或市場分析區塊

• 暫時停留在某個頁面位置

如果背景更新直接重建整個頁面，這些操作可能全部消失。即使新資料是正確的，使用者仍然會覺得介面在和自己對抗。

因此，更新資料時需要同時考慮兩件事：資料是否更新成功，以及使用者目前正在看什麼。

為什麼不直接重新載入整個頁面？

整頁重新載入雖然容易實作，但在資料型介面中有幾個缺點：

• 使用者選擇的 timeframe 可能被重設

• 圖表縮放和捲動位置可能跳回最新資料

• 新聞請求變慢時，可能拖延價格圖表的更新

• 單一 API 失敗時，整個頁面可能一起顯示錯誤

• 使用者看不到的區塊也會重複載入

Gold Dashboard 中的價格、歷史 K 線、新聞、技術分析與市場背景，更新速度並不相同。因此，我把它們視為不同的資料區塊，而不是一個必須同時完成的請求。

圖表資料與使用者位置分開處理

圖表更新時，我希望先保留已載入的歷史資料，再只取得最近一段資料。

目前的處理方向是：

1. 將已載入的歷史 K 線保留在瀏覽器記憶體中。

2. 背景更新只取得最新一段資料。

3. 依照時間戳記合併新的 K 線，而不是重建整個序列。

4. 保留使用者選擇的 M1、M5、M15、M30、H1、H4 或 D1 時間週期。

5. 如果使用者正在查看歷史資料，保留目前的縮放與捲動位置。

6. 只有在使用者原本就在追蹤最新資料時，才將畫面移到最新端點。

這樣可以讓圖表持續更新，同時不會把正在研究舊資料的使用者強制帶回最新價格。

讓不同區塊獨立更新

價格不應該等待新聞完成，新聞也不應該因為分析 API 延遲而整個消失。

因此，前端會依照不同區塊安排更新：

• 價格摘要使用較短的更新週期

• 目前 K 線只更新最近的資料尾端

• 新聞與市場背景使用較長的快取時間

• 技術分析等待 VPS 上的排程工作完成

• 某一個 fragment 失敗時，只標示該區塊的狀態

如果新聞請求失敗，價格圖表仍然可以繼續顯示。這樣的局部更新不只減少不必要的網路請求，也能降低單一服務故障對使用者的影響。

更新狀態不應該破壞畫面

前端取得新資料時，不能先清空目前的內容，再等待新的回應。

比較安全的順序是：

1. 取得新 fragment 或資料回應。

2. 檢查 HTTP 狀態和基本資料結構。

3. 在暫存區完成解析與渲染。

4. 確認內容有效後，才替換目前的區塊。

5. 失敗時保留原本的內容，並顯示「更新延遲」或「使用快取資料」。

這個流程把「告知使用者發生錯誤」和「清空使用者正在閱讀的畫面」分開處理。

對資料型介面來說，一個標示為快取的舊內容，通常比一個沒有說明的空白卡片更容易理解。

隱藏區塊不需要一直更新

如果使用者目前只在閱讀 Price 區塊，頁面下方不可見的新聞或時間軸不一定需要每幾秒更新。

可以在以下情況暫停背景請求：

• 瀏覽器分頁目前不是使用中的分頁

• 手機版的摺疊區塊尚未展開

• 區塊目前位於可視範圍之外

• 使用者已經切換到其他頁面

當區塊重新出現在畫面上時，再先執行一次更新，之後恢復原本的週期。這樣可以減少不必要的請求，也不會讓資料永久停止更新。

從 MT5 到瀏覽器的責任分工

這個使用者狀態維持功能，必須建立在清楚的資料責任分工上：

• MQL5 從 MT5 取得 XAUUSD 價格與 K 線資料。

• Windows Server VPS 上的 Python 排程負責分析與資料轉換。

• WordPress REST API 分別接收與提供價格、分析等資料。

• JavaScript 只更新需要變動的 fragment，並保存使用者目前的畫面狀態。

當每一層的責任清楚時，才比較容易判斷問題是來自資料來源、API、更新流程，還是前端顯示。

目前的限制

這個流程仍然有可以改善的地方：

• 更精確地判斷使用者是否正在追蹤最新 K 線

• 測試不同圖表函式庫對縮放和捲動狀態的保存方式

• 統一各語言介面的更新、快取與無法使用提示

• 增加重試取消與重複 request 的測試案例

• 讓使用者更容易理解目前資料的實際更新時間

Gold Dashboard 目前主要用於資料整理、技術研究與 Web 介面實作展示。價格、新聞與分析資料可能存在延遲、缺漏或暫時無法更新的情況。本專案不提供投資建議、交易訊號、自動交易或獲利保證。

結語

好的局部更新不只是讓資料更快出現在畫面上，也要避免破壞使用者正在進行的操作。

在這個專案中，我嘗試讓價格、圖表、新聞與市場分析分開更新，並在更新前驗證資料，在失敗時保留最後可讀的內容，同時維持使用者選擇的時間週期、縮放與捲動位置。

如果你也有開發資料型 dashboard，想請教你通常如何處理以下問題：

• 背景更新時，你會如何保留使用者的圖表位置？

• 你會把哪些區塊設定為獨立更新？

• 當新資料延遲時，你會如何提示使用者而不打斷閱讀？