樣式和 CSS - AWS 方案指引

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

樣式和 CSS

階層式樣式表 (CSS) 是一種用來集中判斷文件呈現方式的語言,而不是文字和物件的硬式編碼格式設定。語言的階層式功能旨在透過使用繼承來控制樣式之間的優先順序。當您使用微型前端並建立管理相依性的策略時,語言的階層式功能可能是一項挑戰。

例如,兩個微前端共存在於同一個頁面上,每個微前端都會定義自己的 HTML 元素樣式。body如果每個文件獲取自己的 CSS 文件,並通過使用style標籤將其附加到 DOM,則 CSS 文件覆蓋到第一個,如果它們都有常見的 HTML 元素,類名或元素 ID 的定義。有不同的策略來處理這些問題,這取決於您為管理樣式所選取的相依性策略而定。

目前,在效能、一致性和開發人員經驗之間取得平衡的最常用方法包括開發和維護設計系統。

設計系統-一種共享的方法

此方法使用系統在適當的時候共用樣式,同時支援偶爾的分歧,以平衡一致性、效能和開發人員體驗。設計系統是由清晰標準指導的可重複使用組件的集合。設計系統開發通常由一個團隊驅動,他們有許多團隊的意見和貢獻。實際上,設計系統是一種共享可以導出為 JavaScript 庫的低級元素的方法。微型前端開發人員可以使用該庫作為依賴項,通過組成預製的可用資源來構建簡單的接口,並作為創建新接口的起點。

考慮需要一個表單的微前端的例子。典型的開發人員經驗包括使用設計系統中可用的預製組件來組成文本框,按鈕,下拉列表和其他 UI 元素。開發人員不需要為實際組件編寫任何樣式,只是為了它們如何一起看。要構建和發布的系統可以使用 webpack 模塊聯合或類似的方法將設計系統聲明為外部依賴項,以便在不包含設計系統的情況下打包表單的邏輯。

然後,多個微型前端可以執行相同的操作來處理共同的擔憂。當團隊開發可在多個微型前端之間共用的新元件時,這些元件會在成熟度之後新增至設計系統。

設計系統方法的一個主要優點是高水平的一致性。雖然微型前端可以編寫樣式並偶爾覆蓋設計系統中的樣式,但是很少需要這樣做。主要的低級元素不會經常改變,並且它們提供了默認情況下可擴展的基本功能。另一個優點是性能。透過建置和發行的良好策略,您可以產生由應用程式殼層檢測的最小共用套裝軟體。當多個微型前端特定的服務包按需非同步加載時,在網絡帶寬方面佔用空間最小,您可以進一步改進。最後但並非最不重要的一點是,開發人員體驗是理想的,因為人們可以專注於構建豐富的界面,而無需重新發明輪子(例如每次需要將按鈕添加到頁面時寫入 JavaScript 和 CSS)。

缺點是任何類型的設計系統都是依賴關係,因此必須維護它並有時更新。如果多個微前端需要新版本的共用相依性,您可以使用下列其中一項:

  • 一種協調流程機制,偶爾可以擷取該共用相依性的多個版本而不會發生衝突

  • 一種共享策略,將所有從屬項轉移到使用新版本

例如,如果所有微前端都依賴於設計系統的 3.0 版,並且有一個名為 3.1 的新版本以共用方式使用,您可以為所有微型前端實作功能旗標,以最小的風險進行移轉。如需詳細資訊,請參閱 < 功能旗標 > 一節。另一個潛在的缺點是,設計系統通常不僅僅是造型。它們還包括 JavaScript 做法和工具。這些方面需要通過辯論和協作達成共識。

實施設計系統是一項很好的長期投資。這是一種流行的方法,任何在複雜的前端架構上工作的人都應該考慮它。它通常需要前端工程師、產品和設計團隊協同合作並定義彼此互動的機制。安排時間以達到所需狀態非常重要。同樣重要的是要獲得領導力的贊助,以便人們可以長期建立可靠,維護良好和高性能的東西。

完全封裝的 CSS-一個沒有共享的方法

每個微前端都使用慣例和工具來克服 CSS 的級聯功能。一個例子是確保每個元素的樣式始終與類名稱相關聯,而不是元素的 ID,並且類名始終是唯一的。通過這種方式,一切都將範圍限制在單個微前端,並且將不必要衝突的風險降到最低。應用程序 shell 通常負責在將微前端的樣式加載到 DOM 後加載,儘管某些工具通過使用將樣式捆綁在一起。 JavaScript

不分享的主要優點是減少微前端之間引入衝突的風險。另一個優點是開發人員的經驗。每個微型前端與其他微型前端沒有任何內容。單獨發布和測試更簡單快捷。

無共享方法的一個主要缺點是潛在的缺乏一致性。沒有制度來評估一致性。即使複製共享的內容是目標,在平衡發布和協作速度時,它也變得具有挑戰性。常見的緩解措施是創建工具來衡量一致性。例如,您可以建立一個系統,以自動擷取使用無頭瀏覽器在頁面中呈現的多個微型前端的螢幕擷取畫面。然後,您可以在發布之前手動查看屏幕截圖。但是,這需要紀律和治理。如需詳細資訊,請參閱「平衡對齊自主權」一節。

根據用例,另一個潛在的缺點是性能。如果所有微前端都使用了大量樣式,則客戶必須下載大量重複的代碼。這將對用戶體驗產生負面影響。

只有少數團隊的微型前端架構,或者可以容忍低一致性的微型前端架構,才應考慮這種無共享方法。它也可以是一個自然的初始步驟,而一個組織正在設計系統上工作。

共享全球 CSS— 一種共享的方法

使用這種方法,所有與樣式相關的代碼都存儲在一個中央存儲庫中,貢獻者通過處理 CSS 文件或使用預處理器(例如 Sass)為所有微前端編寫 CSS。進行變更時,建置系統會建立單一 CSS 套件,該套件可以託管在 CDN 中,並由應用程式殼層包含在每個微型前端中。微型前端開發人員可以透過本機代管的應用程式殼層執行程式碼,以設計和建置應用程式。

除了降低微前端之間衝突風險的明顯優勢之外,這種方法的優點是一致性和性能。但是,從標記和邏輯中解耦樣式會使開發人員更難理解樣式的使用方式,它們如何演變以及如何棄用它們。例如,引入新的類別名稱可能會比瞭解現有類別及編輯其屬性的後果更快。建立新類別名稱的缺點是套件大小的成長,這會影響效能,以及可能引入使用者體驗中不一致的情況。

雖然共用的全域 CSS 可以是 monolith-to-micro-frontends移轉的起點,但對於涉及一或兩個以上團隊共同合作的微型前端架構來說,這並不是有益的。我們建議您盡快投資於設計系統,並在設計系統正在開發時實施一個無共用的方法。