跳至主要内容
💬 回報這一頁

元件總覽

每個元件一頁,格式固定:用途 → 何時不要用 → 狀態 → 無障礙 → 活範例 → 取用

「何時不要用」是刻意放在第二段的。設計系統失敗最常見的原因不是元件不夠多, 是元件被用在不對的地方——然後大家開始 fork,然後就沒有系統了。

收錄範圍

元件
基礎Button、Badge、Card、Callout
表單Input、NumberInput、Label、Checkbox、Select、SegGroup、Chips
浮層Tooltip、Dialog
資料Table、DataTable、TabPills、Delta、EmptyState、Stepper
進階表單EditableField、ChangeSummary
引導Coachmark
圖表BarChart、Pareto、StackedBar、TrendChart、Bullet、Scatter、Heatmap、LineChart、Legend
文件用Placeholder / Spotlight / MockScreenFrame

不收什麼

  • 完整的圖表庫——圖表只收「後台閱讀型」的八種零相依圖, 刻意不做縮放、刷選、圖內鑽取,資料點也只撐到百位數。 需要分析型互動請直接用成熟圖表庫,不要改造這一組。
  • ErrorBoundary、Layout、Sidebar——這些是應用外殼的職責,不是設計語言。 導覽層的規範見後台系統的資訊架構
  • 任何綁定特定業務流程的複合畫面——它們在原專案裡是對的,抄到別的產業就是錯的。 去領域化之後仍然成立的頁型組成規範(清單頁、明細頁、表單頁…)收在頁面章, 以文件與組合 story 的形式存在,不發元件。

共同約定

  1. className 一律可覆寫,內部用 cn() 合併,後者勝出。
  2. 不吞事件——所有原生 props 透傳。
  3. 不自帶資料抓取——元件只接受 props,狀態由宿主決定。
  4. 文案可覆寫——多字串元件(DataTable、Coachmark、EditableField)都吃 labels prop。
  5. 不依賴任何應用層概念——由守衛測試強制。
  6. 分類色與狀態語意脫鉤(雙向)——圖表序列色只表達「這是哪一類」, 好壞一律走 successwarningdanger;反過來,維度本身是狀態時必須沿用狀態色。 判斷樹見圖表的配色策略