微前端系列（五）

接著就是以 Component 化的角度來看看微前端的實作方法。

• iframe

• WebComponent

• Frontend Framework Component (react, vue, angular)

iframe

這是最古老最穩定的方法，副作用也是最少的，最不容易發生污染的解決方案。

但這方法的缺點卻也是最多的。

溝通麻煩，需要透過 Dom 取得後由外而內，卻不容易由內而外溝通，跨域時更甚至需要依靠伺服器端來進行溝通。

這方法也同時非常吃資源，它會消耗非常驚人的記憶體和運算資源，沒辦法進行大量掛載。

另外就是 SEO 的扣分，它可能比 CSR 造成的影響更大。

WebComponent

原生的組件化解決方案，對於各種環境與架構相容性較好。

實體生成與註冊不強制順序，更容易額外封裝。

具備 Shadow DOM 功能，可以隔離 document 的作用域。

優點很多，缺點也不少。

對 SSR 不友善，需要搭配 SSI 相關技術。

拓展功能不如框架的 Component 好用，需要基於 DOM 元件的基礎延伸。

Shadow DOM 也是一把雙面刃，徹底隔離也帶來一些麻煩，後面會額外探討。

Frontend Framework Component

使用框架的 Component 可以說是幾乎沒有學習成本，使用最直覺。

資料傳遞可以直接依附框架的機制溝通，處理起來更加容易。

建構時也可以大量縮小程式體積，有效降低總程式碼的大小，盡可能重複利用。

對應的 SSR 方案整合度高，容易被實作。

但對於這種解決方案，也有致命問題。

微前端應用被綁定在特定的框架、版本上，當要升版和整合時很容易因為版本不一致損壞。

因為溝通變得容易，元件和元件在開發上容易不自覺提高耦合度，採用很多不易反查的手法。

使用上會有種犧牲一些微前端的好處來換取架構上與撰寫上的便利，但又有點本末倒置，甚至有種不如別用微前端好的感覺。