微前端系列（十二）

路由器設計

在微前端架構中，路由器（Router）是不得不面對，而且情境極複雜的一個議題。

因為 browser history 的對象在整個前端應用程式是唯一的，不會存在第二個。但如果有多的前端應用程式產生出多個 history 的操作器，那高機率就要打架了。在整個運作系統之中，最怕的就是「改了不動」、「改了不知道」、「遞迴循環修改」等情境。

其實看過各大框架系統，都不太推薦微前端模組另外開自己的路由系統，多半鼓勵以「原子化元件」作為切分點。如果以元件切分，確實路由議題可以全然仰賴上層主應用控制，它本身的渲染控制便不在元件邏輯內。

但相信做過微前端的都知道，你每個微前端切分成本很大，會希望一個應用包裝更多功能而不要切分，這就延伸新的問題「路由器的狀態同步」。狀態同步議題其實回到上一篇講的「單例狀態管理」，解決方案是一致的。

說穿了，就是微前端應用「不要直接操作路由器」，那不操作路由器該怎麼操作與通知？其實是一樣的解法，採用單向資料流的方式統一管理，讓可以改變狀態的窗口全部一致在某個觸發點，不能全世界好幾個地方能改。當單向資料流徹底管理後，就可以很容易去攔截所有路由的副作用，如此一來就可以建構狀態管理系統去「取得」、「修改」、「監聽」，行形成一套資料流。

這個問題真的搞了我很久⋯⋯