瀏覽器路由

又來到微前端踩坑分享，這次是 browser history router。經過多種方案的路由器方案研究，每一種方案都看似完美，但都會在進入實作時發現新的坑。其實，路由器製作看似很簡單，卻也很複雜，背後運行上有很多想不到的小細節。

路由器的資料流裡面有幾個關鍵的 Action，分別是 history.pushState, history.replaceState, history.forward, history.back。其中除了 push 和 replace 是常見的「靠 JS 主動換頁」外，還有 forward, back, go 三種方法是瀏覽器換頁。製作最麻煩的大概就是「監測換頁」這件事，因為主動換頁是無法單單靠事件來監聽到所有換頁。你可能認為不是有「popstate」這個 event 可以監聽嗎？但事實上它只能監聽 forward, back, go 三種操作，而 pushState, replaceState 的行為是沒辦法監聽的。

我其實很想要重頭刻一個 router library ，但想到背後踩坑和維護成本，不禁想像覺得還是先不要，畢竟每一行程式都是維護成本。加上我花了很多心力研究 open source 的 library 評估其複雜度，包含它的實現原理和實作原理，確保我設計方式不會與其產生衝突。

最後我得出的結論很簡單，就是 「整個應用能操作 history 的只能有一個」，其實原理就是，多狀態要相互同步，主狀態只能有一個，這樣才能確保資料流穩定。

其實實作各種微前端開發，我漸漸發現要處理資料流同步都離不開一個道理，就是「單向資料流」。不要依賴任何雙向同步的架構，要讓整體資料流採用單向移動，減少「相似判斷」， isEquel 絕對是超級耗能且不穩定的設計，我非常不推薦這種操作手法。

不知道下次又要踩什麼坑，不過留著給未來的自己煩惱吧。