在 AmazingTalker 開始建立 Component Library
在開發一個持續成長且需要長期維護的網站時，在前端的部分為了維持產品的一致性、減少 UI/UX（User Interface/Experience）上的溝通成本，以及減少重工以提升開發效率，通常我們會以一份 Design Guideline（設計準則）為基礎來建立一套 Component Library（元件庫），這點對於 AmazingTalker 的網站來說也是如此。
以下這篇文章記錄的便是我們從 2021 年開始於現有專案中建立 Component Library 的過程。
為什麽我們需要建立 Component Library？
時間回到 2021 年初，當時的我們在設計與實作 AmazingTalker 網站的 UI/UX 時，主要是以使用 3rd-party UI Framework（第三方 UI 框架）的方式來處理的，當時我們同時使用了 Bulma、Element 和 Vuetify 三套 Framework，雖然部分的 Component 也有被封裝起來，但基本上是走一個 Framework Oriented 的方向。
在產品開發的前期，這樣的方式有其優點，像是能減少 PD（Product Designer）製作 Design Spec 所需的時間、加快 Engineer 開發的速度等，但相對的也有其潛在的問題，像是過多不必要的程式碼而造成的效能影響、為了對框架客製化而造成的程式複雜度上升等。
其中，真正讓我們感到困擾的則是隨著產品規模與團隊人數的持續成長，Framework Oriented 的方式造成了越來越顯著的溝通成本的增加，以及開發效率的降低，例如，我們會需要來回確認 Framework 提供的 UI 是否能符合我們 Design Spec 的需求？該如何客製化才能有好的擴充性？新加入的成員想知道某個 UI/UX 最正確的使用與實作方式的話，需要花時間去比對 Framework 的文件和程式中已經存在的各種客製化等。
這些增加中的成本促使我們決定要將 UI/UX 的實作改以 Component Oriented 的方式來進行，由我們自己設計與控制 Component 的各項變數、文件與範例等，來提供團隊一個更簡潔的溝通方式和更好的 DX（Developer Experience）。而這樣一個開發思維上的改變，我們期望以建立 Component Library 的方式來推行，這便是我們需要建立 Component Library 的理由。
開始建立 Component Library
決定開始建立 Component Library 後，我們選擇先從 Typography 下手，製作一個相對簡單的 text Component 並實際用在產品上，來驗證是不是能解決我們前面提到的問題。這個選擇主要是因為 text 是 UI 中最基礎的 Component 之一，可預期實作起來是相對簡單、風險小，卻又可以快速推廣到整個產品從架構上做到改變的範例。
接著則是溝通的部分，我們再次和 Designer 確認了 Design Guideline，和 PD 確認了未來 UI/UX 的規範、開發與擴充方式，並與 Frontend Engineer 協調 Component 的開發準則以及取得 Component Library 在 Folder Structure 上的共識。
// Component Library's Folder Structure
components
|- common
|- at-text
|- index.vue有了共識之後，接著便是著手實作、寫測試，並使用在產品上。下面是我們第一個 Vue 版本 text Component 的 pseudocode，基本上是單純透過 prop 封裝了 Guideline 裡定義的各種 type。
同時我們也以 Storybook 建立了一個 Showcase 網站，透過 Github Actions 建立 CI/CD 將 Showcase 網站 deploy 到 AWS S3 上，讓所有人（Designer、PD、Engineer）都能隨時輕易地參考與試用 Component。
到此為止就算是完成了我們預期中的第一個 Component 以及 Component Library 的基礎架構，也是將 UI/UX 的開發思維從 Framework Oriented 調整成 Component Oriented 的第一步，之後我們便開始了一段時間的觀察與持續擴充。
觀察與結論
截至目前（2022 年中）為止，因為 Component Library 的建立而提供的易於取得與理解的規範性，我們確實改善了最初發現的溝通成本與開發效率的問題，除此之外，因為 Library 擁有的彈性架構以及良好的 DX，大家也會願意持續進行 Component 的擴充與維護，例如新增更多功能到 text Component 裡，封裝出更多的基礎元件（button、link 等）、將較複雜的 Component 使用的 Framework 抽出需要的部分封裝進 Library 裡等，儘管偶爾還是會有 Design Spec 和 Component 不合的情況發生，但大方向上都有往持續改善中的方向前進。
回頭來看，要開始建立一個 Component Library 在技術上來說其實並不困難，較多的心力反而會花在取得團隊共識的溝通與協調上，以及在現有專案、產品上持續推行的執行力。當然，Component Library 這個主題未來也還有許多可以進一步嘗試與鑽研的項目，像是 Component 的穩定完整的測試、更完整且自動化的文件、效能的優化與監測、跨專案間的共用等等，未來如果還有更多更深入的心得的話我們也很樂意再與大家分享。
🔥 如果你在看完文章後對 AmazingTalker 團隊有興趣的話，歡迎從這裡進一步了解我們的團隊。
