元件真的別亂自己刻

經歷多份工作，和各個團隊合作，也多次面試時詢問各家公司情況，和驗證各大函式庫，慢慢有一個造元件的思路。

以前能力還不成熟時，經常夢想可以自造元件庫，能夠打造一個好用、多元的UI元件庫。但隨著經驗累積，自己嘗試打造多次元件之後，發現造一個元件庫面臨的問題真的是多如牛毛，還有許多問題得面臨。

光一個 Custom Select，就有八個坑

以前我常常會舉個例子，使用 div 製作一個 Custom Select Component ，會遇到什麼問題呢？

• 用什麼方式讓選單浮出來？
• 展開動畫要怎麼做才不會不自然？
• 內容過多該怎麼顯示？
• 點擊了空白處要怎麼自動收合？
• 滾動了外部的滾動吧是否會被跟著移動？
• 如果元件放置在外部有 overflow 的容器上，該怎麼處理會被切掉的問題？
• 當下拉選單打開，如何讓報讀器知道下拉選單被打開？
• 當操作者使用鍵盤時能被操控嗎？

簡單的一個元件就有數不清的細節，如果沒有充足的製作經驗，就會做出很多缺陷的元件。

手刻元件，是在製造高昂的開發成本

我聽過的不少公司都手刻了自己的 UI 元件，也不是基於某個 UI 庫，而是為了自己的樣式與行為手刻。我認為這樣其實會埋下很多問題因子，無形在製造高昂的開發成本。

另一個隱形成本：維護與使用

另外一個自製元件的隱形成本，就是維護和使用。

• 元件是需要被反覆使用的，如果元件狀態不穩定是很容易發生大範圍問題，需要足夠的單元測試和整合測試維持。
• 元件製作後是很多互動細節的，需要密切和 UI 設計師協作，這時是需要有 UI Preview 工具，如 storybook 之類的工具來便利於溝通和細節確認。
• 當元件數量上升，以及不斷有人員流轉，慢慢元件當初設計的資訊就會遺失，也很有可能不斷發生元件重刻的情況。最好有元件文件，標示所有元件的列表，也要知道元件功能上有哪些 API 可以被使用。
• 元件為了方便給跨 Repo 使用，也為了確定完全與業務邏輯解耦，這時必須把元件整個包成一個 package ，相對需要把所有元件程式打包整合。

或許是因為並不需要每一個細節都做到，但相對也需要規劃設計，並長期把這些基礎建設完成。如果沒有處理這些細節，也是長期積累下技術債，未來終究需要人來償還。