UI組件是一個非常困難的問題。只是選擇一個UI框架或者在一些設計模擬上進行迭代，一切都會得到解決。對嗎？

　　問題是，我們解決問題的大部分方法都來自于研究小項目。在小型項目中，我們可以使用一個樣式表，或者在UI框架上迭代。

　　在一個使用大量的產品的大型組織中，這不會奏效。 以下是可能出錯的細節：

　　缺乏規劃和架構

　　設計師為產品創建高保真的模型。

　　前端團隊將設計實現到應用程序中。

　　應用程序大小的增長。

　　隨著應用的發展，前端團隊創建了一個庫來“共享”代碼。

　　浪費時間和停滯

　　產品需要對其中一個組件進行更改，但該組件現在在20-30頁。

　　開發人員不愿做出改變，因為擔心它會在其他地方“崩潰”。

　　由于團隊擁有站點的不同部分，開發人員甚至不知道什么可能會中斷。

　　瓶頸的產生是因為變化是高風險的。

　　不一致

　　現在產品負責人“A”她不喜歡一個選擇框，所以她讓設計師模擬出了一個她喜歡的新的選擇框。

　　創建了一個新的一次性組件，它將被輸入到代碼庫中，而不需要團隊的其他成員對此進行了解。

　　現在有兩個選擇框。

　　選擇框的更改不會在應用程序中傳播。

　　現在，不僅存在瓶頸，還存在設計上的不一致。這一過程也缺乏團隊的支持。

　　高風險/復雜性和條式代碼

　　現在有人提交另一個設計請求。

　　全局樣式表的尺寸越來越大，以至于掩蓋任何其他樣式。

　　該組件引用了一種基礎樣式，它將以一種不受歡迎的方式更新許多內容。

　　所以創建樣式拼圖，重要的是添加，現在…

　　認真的…開發人員已經開發結束了，設計師已經退出了，產品主人仍然在問為什么簡單的改變是如此難以做到。

　　幸運的是，有非常聰明的人努力解決這些問題。 那么我們如何解決呢？ 下面這是如何添加一些結構的清單：

　　步驟1：構建組件庫

　　即使您的組件庫引用了一組開源組件，也可以構建自己的庫和版本。不僅如此，為庫中的所有組件創建包裝器。這樣，如果您需要將某些東西交換出來，則不需要更改外部API。您只需要修改實現細節。

　　組件庫應該是應用程序的核心。所有的應用程序都需要這個庫。不要在您的應用程序中編寫組件和“向后移植”，而是在前面的組件上工作。這將生成更好的代碼和更有意義的應用程序。

　　組件庫的另一個優點是所有開發人員可以隔離和觀察更改。特別是如果您正在管理GitHub中的代碼，并在在合并之前需要提取請求。

　　在一個單一的應用程序中，很容易將變更轉移到一個導致不一致的功能分支上。有了一個組件庫，人們就可以抵制牛仔編程。

　　步驟2：將您的整體前端拆分成較小的應用程序

　　如果您的應用程序有很多頁面，那么您應該嘗試將所有這些頁面移動到它們自己的SPA（單個頁面應用程序）中。這個系統的美妙之處就在于，當您對組件庫進行更改時，您可以對所有應用程序進行漸進的更新。它使你不必去做“一個巨大的更新”。

　　這減少了開發人員對更改導致更多工作的擔心。團隊能夠按照自己的進度管理更新。不需要有一個巨大的組織推動來更新一個按鈕。

　　步驟3：使用CSS模塊隔離組件設計

　　CSS模塊允許有兩種情況。第一，他們擺脫了全局類暴露的問題。這意味著當您為組件更新一個類時，您確切知道將會更新什么，因為樣式的范圍是相對于組件的。

　　第二個主要優勢是，開發人員知道所有樣式都在哪里。他們不必擔心樣式表會在一組普通的樣式表上分散開來。

　　步驟4：使用交互樣式指南作為用戶體驗、產品和工程之間的合同

　　任何組件庫都應該能夠發布交互式樣式指南。對于開發人員、產品團隊和設計人員來說，這是一個中間地帶。它允許您隔離您的組件并獨立地處理它們。你可以更快地工作，看到變化更快。最好的部分是，一旦您發布了更新，它將通過整個應用程序傳播這些更改。

　　交互式樣式指南就像是故事書。它不僅捕獲了外觀和感覺，還公開了響應組件的狀態（在工作中對Vue支持）。

　　既然您已經知道了所有組件的位置，就不需要每次都交付高保真的模型了。設計師可以更多地關注行為、信息設計和用戶體驗。開發人員在開始新功能時不必擔心設計問題。他們可以專注于業務邏輯和復雜的行為。

　　這種方法的潛在流程如下：

　　一個特性請求通過并被分解成一組組件。

　　前端開發人員決定該特性是否需要新的組件或更改。

　　如果沒有，那么特性開發就可以開始了。

　　如果需要新的特性，開發人員將在組件庫中創建一個特性分支。在產品、UX和其他開發人員的交互式風格指南中，這些更改將被評審。

　　一旦更改或新組件被批準，該分支就被移動到主文件中。

　　根據更改的不同，這個庫的新版本是在semver之后創建的。

　　將應用程序的設計抽象為一組組件，并開發成組件庫。該庫應使用NPM進行版本控制。打破API或可能的主要設計變更將保證主要版本的更改。

　　應用程序的部分被分解為具有自己的package.json的SPA（單頁面應用程序）。這允許他們以可控的方式對組件進行升級。

　　新組件或更改在開始特性開發之前就已經確定了。產品、UX和工程可以使用交互式樣式指南在組件設計上進行協作，并在站點上看到一個“真實”的副本。更改并不可怕，因為如果存在與更改相關的風險，開發人員可以使用版本控制來減輕影響。另外，現在使用CSS模塊對組件樣式進行隔離，因此對組件“a”的更改不會影響組件“b”。

　　用戶體驗現在可以交付低精度的模擬組件，根據名稱來引用組件。開發人員知道要使用哪些組件，不需要在“共享”代碼的某個地方“釣魚”。

　　另一個設計？沒有問題。我們將在組件庫中創建一個分支，并更新所有樣式。當我們準備發布時，我們將創建一個主要的版本更新。問題就解決了。

　　缺點呢？

　　將“整個應用”更新仍然會有支持者。

　　將應用程序拆分為小應用程序可能會對某些產品造成規模太大的問題。

　　預先設計組件需要滿足團隊中大量的規范。并不是每個人都能夠抽象需求并據此制定計劃。

　　牛仔編程仍然可以實現。你的庫和你的程序需要一個所有者。

　　這不是一個容易的跳躍，它需要整個組織的支持。如果您的目標是在增加團隊速度的同時減少瓶頸和草率的更新，那么上面羅列的就是您的方法。如果你仍然相信“推送”按鈕的更新。祝你好運！當你看到速度下降和成本上升時不要感到驚訝。