Jing Tech 前端技術週報 #5

🎨 Design System | 👨‍💻 本週精選

Hi！這裡是 Jing Tech 前端技術週報，上週筆者確診 Covid 所以停更一次，目前緩慢回復中！除了 Substack 電子報外，也可以在筆者的部落格 jing-tech.me 與 instagram: jing.tech 關注前端大小事！

本週深度閱讀

The Design System Ecosystem

設計系統 (Design System) 發展至今已相當成熟，其概念也成為多數前端團隊的標配，對筆者來說設計系統沒有一個標準的實作方式，它類似於一個架構，我們可以根據這個架構底下去打造符合團隊需求的系統。它可以很簡單也可以很複雜的，隨著團隊的規模的增長，設計系統的責任與複雜度也會跟著增加。

文內將設計系統可以分成四大層，層與層之間是相互連結的，而本篇會結合筆者的經驗由底層開始介紹至最上層：

1. Core Design System

   首先最底層的就是設計系統的核心這裡面包含了設計標籤 (Design Token)、圖示 (Icon)、UI 組件庫以及文檔

   1. 設計標籤 (Design Token)

      1. 它是最底層的設計定義 (Design definitions)，像是 color, typograph 與 spacing 等等，也是品牌的核心，這些標籤最終應用於 UI 組件上，而它也在原子設計裡被稱為次原子粒子 (subatomic particles)。

      2. 其重要的地方在於它提供了單一資料來源 (Single Source of Truth) 以及扮演著跨團隊間的溝通語言。

      3. 設計標籤通常會以抽象到實例化進行分層。舉 Material Design 為例，它將設計標籤分為 reference、system 以及 component，實作上就是將層層進行索引 (例如一個按鈕的顏色，其索引會是 ref.palette.primary.40 → sys.color.primary → filled.button.container.color)，而這個分層概念也可以讓同一套設計系統支援多個品牌、深淺模式等。

         

      4. 設計標籤的實作核心就是多個 JSON 格式的鍵值表 (key-value) 來儲存設計標籤，最終將這些 JSON 檔轉化成對應的技術格式 (CSS, SASS, iOS and Andriod)，常見的工具像是 Style Dictionary。

      5. 通常大廠 (Github - Primitives, Pinterest - Gestalt 等) 會將設計標籤分拆成另外一個 repo, 而這個 repo 就是設計師與各平台工程團隊的溝通橋樑，同時也可以透過 Figma 插件去做自動化，每當設計標籤在 Figma 有改動時就會同步到該 repo，改顏色等就雜事就不再需要工程師的參與，而是透過自動化完成。

   2. 圖示 (Icon)

      1. 圖示也跟設計標籤一樣是獨立的存在，最終會透過打包工具，將 SVG 等格式轉換成適當的技術格式 (JSX, …)。

      2. 圖示套件可以是公司內部所設計在轉換成程式碼或是可以直接使用開源的圖示，例如 Lucide。

   3. UI 元件 (UI Component)

      1. Design System 概念中的代表，當我們想到設計系統時，第一個可能會想到的是 UI 元件庫。

      2. 對於設計師來說，設計系統是一個獨立的專案，負責設計系統設計師會在這裡設計元件的規格、使用方式等等的最佳實踐。而產品設計師就直接從設計系統庫裡面選取組件並拉到產品設計中，達到設計一致性。

      3. 對於工程師，則是根據設計系統的設計稿透過程式碼進行實踐，以前端網頁工程師來說可以用 Web Component 去實踐 UI 元件 (像是 Lit 跟 Stencil 都是多數公司採用的庫)，當然也可以用 React、Vue 或是 Angular 等 UI Library 去實作，但公司所有專案就必須以特定語言去開發，多數大廠是同時並行 (例如 Adobe 的 Spectrum Design System, IBM 的 Carbon Design System)，同時也可以搭配 Storybook 與 Chromatic 對 UI 做呈現與測試。而最終目的就是減少團隊的重工與產品的一致性。

   4. 文檔

      1. 不僅僅限於設計系統，筆者認為文檔是所有工具套件等項目最重要的一環。而一個好的設計系統文檔必須要能夠降低團隊間的溝通成本，例如對於工程師最關心的就是能夠將範例上的程式碼複製貼上，簡單修改一下就能夠完成他所想要的功能。

      2. 多數開源設計系統的文檔可能是用 Storybook (例如 Monday.com)，更進階一點的可能直接建立網站，也可以用 Zeroheight 等的第三方工具協助文檔的建立。

   5. 未來的設計系統

      1. Web Component 的成熟

         1. 隨著時間推移，基於特定於框架的實作將會減少，大多數的框架都會基於 Web Component 去實踐，從以前某些特定 UI 套件 (e.g. React) 無法支援 Web Component 到現在這大多已不是問題。

2. 食譜層 (Recipe Layer)

   多數小廠都沒有一個專職的設計系統團隊，儘管大廠有，但人數遠不如產品團隊這麼多，然而當 UI 元件需求排山倒海而來時，往往會讓設計系統團隊分身乏術，而食譜層就如同字面上意思，讓產品團隊先行實現組件設計與實作，而設計系統團隊可以隨後用更審慎的方式將其進行實作加入到核心 UI 庫中。

3. 智慧層 (Smart Layer)

   智慧層則是將核心 UI 庫添加邏輯，舉例來說表單除了輸入框、圖片上傳、確認鈕等的 UI，在實作上我們要考慮到驗證、狀態的交互等邏輯，而智慧層可以將這些邏輯與核心 UI 庫進行封裝，這樣就可以避免開發者重複造輪子的時間成本，可以將更多精力放在業務邏輯開發上。

4. 產品層 (Product Layer)

   最終這些經過封裝的 UI，就可以在開發中開箱及用，加快工作流程。

上面的每一層都是可選的，不必一開始就將設計系統設計的非常複雜，特別是產品迭代速度非常快的初創公司，可以先簡單的將重複的程式碼放到新的一個檔案夾底下，之後隨著產品越來越穩定與多樣化再進行優化，而這些最終的目的都是加快產品的開發，強化產品的一致性以及減少團隊的溝通成本。

文章是出自 Brad Frost，他是著名原子設計一書的作者，文內給出了一個設計系統 (Design System) 大致的框架，也跟筆者實際遇到的經驗非常相符，是一篇非常值得閱讀的文章。

本週熱點與選讀

文章

1. Derivations in Reactivity

   文章介紹當前 Reactive 框架的特性，可以了解當前 UI 庫背後的心智模型、也說明派生(Derivations) 與同步 (Synchronization) 的差別以及在狀態更新上面使用 Push, Pull 與 Push-Pull 其各自的特色。

2. The Eight Golden Rules of Interface Design

   文章列出了八個黃金設計準則，首先是產品的一致性 (類似的行為應有一致動作)、通用性 (讓產品能符合各種使用者的需求，像是為新用戶添加使用說明，而老用戶能夠使用快捷鍵等)、提供回饋 (像是點訂閱按鈕出現動畫)、設計彈窗以達成結果明確性 (例如好的電商網站應讓使用者從選擇產品、結帳到結帳成功整個流程非常順暢)、防止錯誤 (介面應讓使用者無法製造出嚴重的錯誤)、允許動作是可逆的、讓使用者保持控制權最後則是減少使用者短期記憶的負擔。非常推薦閱讀！

3. Rust-Based JavaScript Linters: Fast, But No Typed Linting Right Now

   基於 Rust 所建置的前端工具不斷推出，像是 Biome 與 Oxc 這類的 Linter 工具標榜比 ESLint 快數十到百倍，但其依然許多功能沒有支援，例如 type-checked linting，並未支援用 JS 客製化 lint 規則。文章內詳細分析了目前 Rust-based Linting 工具的進展，TypeScript 型別檢查 API 效能問題以及當前可能的解決方案，最後點出這些工具還有很長一段路要走。

4. The hardest part of building software is not coding, it's requirements

   AI 是否取代工程師至今已經有需多討論，但身為開發者最常遇到的多為不斷與需求方來回溝通並釐清需求大於功能實作上遇到的問題，AI 目前更像是輔助工具而非替代者。它能夠在程式碼層面提供幫助，例如用更現代的語言翻新老舊軟體 (例如銀行業所使用的 COBOL)，但在需求分析和創意上仍然需要仰賴開發者的判斷力和創造力。這也跟 Remix 核心成員 Ryan Florence 的觀點非常像，他推文提到：One programmer good at programming and Ai will replace a team of programmers though。這個時代開發者要能夠熟練地使用 AI，除了可以降低被淘汰的風險，如果開發者本身有產品或商業洞見，這反而能夠為你開啟了更多機會大門。

5. The future of React.use and React.useMemo

   React Context API 推出後解決了 Prop drilling 的問題，但可能導致了不必要的重新渲染進而影響效能，原因是當 Context 的值發生變化時，所有消費該 Context 的組件都會重新渲染。這意味著，即使只有一小部的資料改變，也可能導致整個組件樹中的許多組件進行不必要的渲染。對此社群也已提出不同的解決方案，像是 Daishi Kato 所開源的 use-context-selector，而在不久後，開發者可以用 React 原生的 API React.use + React.useMemo 解決此問題 (X 推文)，最後當 React Forget 正式推出後，這個問題就不再是開發者需要擔心的了！

6. Zustand v5-alpha

   Zustand v5-alpha 在本週推出了，並且打包後的大小只有 622 B (Minified + Gzipped)，而 Zustand 的程式碼非常簡單，僅用約 50 行就實現了一個狀態管理的套件，非常推薦大家讀該套件的原始碼。

影音

1. Docker Tutorial for Beginners | Dockerize Any App in 2024

   講者用淺顯易懂的方式介紹了 Docker 以及如何將應用進行 Dockerize，推薦給想要初探 Docker 的讀者們！

播客

1. Front End Happy Hour - EP 184 | Online learning on the rocks

2. Rust in Production | Apollo

本期內容就更新到這裡，感謝大家的閱讀，如果有任何問題或想法歡迎一起討論，也歡迎分享給更多人知道！你的每一份支持，都是我持續創作的動力！更多關於我的創作可以點擊這裡。