Day 11：為什麼專案的 Component 越拆越多？

2026 iThome 鐵人賽

DAY 11

Modern Web

Vue 演進驗證 × AI Coding 時代的工程實踐系列第 11 篇

18th鐵人賽

kuku

2026-09-11 08:30:09

25 瀏覽

分享至

拆組件的原則是什麼？要拆多細？

前一個階段，我們花了幾天處理 Reactive Chain Hell，得到一個很明確的結果 Vue 可以改善 Runtime Cost，但 Reactive 怎麼設計，仍然是 Architecture 的問題。

接下來換一個大型 Vue 專案同樣常見的問題：Component。

專案一開始通常沒有這麼多 Component

拿一個後台 Dashboard 來看，一開始可能只有：

Dashboard
├── Header
├── Sidebar
├── Statistics
├── Table
└── UserDialog

需求慢慢增加後，結構會開始長大：

Dashboard
├── Header
│   ├── UserMenu
│   └── Notification
├── Sidebar
│   ├── MenuItem
│   └── CollapseButton
├── Toolbar
│   ├── SearchBox
│   ├── FilterPanel
│   └── ExportButton
├── Statistics
│   ├── RevenueCard
│   ├── UserCard
│   └── OrderCard
├── Table
│   ├── TableHeader
│   ├── TableBody
│   └── Pagination
└── UserDialog
    ├── UserForm
    └── PermissionPanel

這時候很容易出現 Component 再拆會不會太細？ 但如果完全不拆，另一個問題又會出現。

不拆，也不代表比較簡單

我曾經接手過一個大型後台專案，隨便一個 .vue 檔案都超過 4,000 行，當時最直接影響專案的問題是 任何修改都很難判斷會影響到哪裡 ，導致只要提交新需求，每次 QA 就要全後台重跑自動化測試！

這其實讓我重新思考一件事：Component Count 跟 Architecture 之間關連性是什麼？

如果 Component 少 ≠ Architecture 簡單；相反的，Component 多 ≠ Architecture 複雜。

我們是不是反而要關心 Component 之間的責任，到底怎麼切 ？

Component Count vs Architecture

Component 拆開了，為什麼還是會變複雜？

例如一個 UserDialog ，隨著需求增加，它可能開始需要：

User
Permission
API Status
Theme
Locale
Feature Flag

最常見直接的方式，就是全部從 Parent 傳進去：

<UserDialog
  :user="user"
  :permissions="permissions"
  :theme="theme"
  :locale="locale"
  :api-status="apiStatus"
  :feature-flags="featureFlags"
  @save="save"
  @delete="deleteUser"
  @cancel="cancel"
/>

這段 Code 不一定錯，也會跑，但是它透露了一個值得注意的訊號：

Parent 已經開始知道 UserDialog 裡面很多事情，只是這些 Dependency 為什麼需要跨過這個 Component Boundary？

Boundary 比 Component 數量更值得注意

可以把 Component 想像成一個有責任範圍的單位，好比一間公司，部門人力不是越少越好，也不是越多越好，理想狀況是大家有自己的邊界範疇知道自己要做什麼！

        Component
            │
     ┌──────┴──────┐
     │             │
   自己負責       對外介面
     │             │
     └──────┬──────┘
            │
       清楚的 Boundary

當 Boundary 合理時，Parent 不需要知道 Child 的所有內部細節；反過來，如果 Component 拆開了，卻出現大量：

Props
Events
Imports
Shared State
Cross-domain Dependency

代表 Component 被拆開了，但責任沒有真正被分開，這才是 Architecture 開始變複雜的地方。

但這裡還有另一個問題

到目前為止，我們談的都是 Architecture，可是 Component 拆開之後，Component 越多，Runtime 真的會越貴嗎？

Component Tree 很大
        ↓
      不代表
        ↓
每次 Update 都會更新整棵 Tree

反過來：

Component 很少
        ↓
    也不代表
        ↓
Update Cost 一定比較低

所以接下來，我們要把問題從 Architecture 拉回 Runtime。

第二個假設：Component Storm

第一個假設，我們研究的是：

Reactive Chain
      ↓
Reactive Update
      ↓
Runtime Cost

第二個假設則換成：

Component Tree
      ↓
Component Update
      ↓
Runtime Cost

而是建立一個可以控制 Component 數量與結構的實驗，探討 Component 越多 → Runtime 越慢 是否成立？

Component Storm

10 Components
      │
      ▼
100 Components
      │
      ▼
500 Components
      │
      ▼
1000 Components
      │
      ▼
Component Storm
      │
      ▼
Measure: Mount + Update

當 Component 數量開始增加，Runtime 到底付出了多少成本？ 不能靠 Component 很多應該會很慢，全部憑感覺來猜，下一篇，開始建立 Component Storm 環境邏輯。