Day 12：建立 Component Storm Validation Scenario

2026 iThome 鐵人賽

DAY 12

Modern Web

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

18th鐵人賽

kuku

2026-09-12 12:34:02

46 瀏覽

分享至

把「Component 越多是否帶來 Runtime Cost」轉成一個固定的 Mount / Update 實驗

上一篇，我們完成了第一個假設 Reactive Chain 的階段性驗證；這一次，問題換成了 Component。

Component 拆分本身可以改善程式碼的組織與維護，但當 Component Tree 持續變大時，另一個問題就值得驗證：

Component 數量增加後，Runtime Cost 是否也會跟著增加？

這就是第二個假設：Component Storm。

先把 Component 數量變成唯一變數

如果想知道 Component 數量是否影響 Runtime Cost，最直接的方法，就是讓 Component 數量可以被控制。

所以在 component-storm\config.ts:L19 定義三種規模：100、500、1,000 Components，但有一個前提：Component 本身不能跟著變。

Template、Logic、Props 與測試環境都固定，只改變 Component Count。

條件	100	500	1,000
Template	相同	相同	相同
Logic	相同	相同	相同
Props	相同	相同	相同
Environment	相同	相同	相同
Component Count	100	500	1,000

這樣後面比較 Vue 3.5 與 Vue 3.6 時，才不會同時改變測試情境，簡單來說，Tree 可以變大，但 Tree 裡面的 Component 不變。

Component 變多，要從哪裡開始看？

Component Tree 變大之後，至少會遇到兩個不同的情境。

第一個是：第一次把這棵 Tree 建立起來，要花多少成本？

第二個是：Tree 已經存在之後，Parent 發生一次 Update，又要花多少成本？

這兩個情境雖然都屬於 Component Runtime Cost，但發生的時間點不同，代表的問題也不同，所以 Component Storm 會把測試拆成：

Component Tree 變大
        │
        ├───────────────┐
        ↓               ↓
   第一次建立        Tree 已存在
        │               │
        ↓               ↓
      Mount           Update
        │               │
        ↓               ↓
   建立成本          更新成本

第一情境：在 Mount 階段建立一棵更大的 Tree

假設現在建立 1,000 個 Child Component，用數據觀察 Component 數量增加後，第一次建立 Component Tree 的成本如何變化？

App
 ↓
Parent
 ↓
1,000 Child Components
 ↓
Create Instance
 ↓
Render
 ↓
Mount DOM

因此 Mount 階段會記錄：

Mount Time
JavaScript Execution
Memory Footprint

第二情境：Tree 已經存在之後的 Update

Mount 完成後，Component Tree 不再重新建立，這次只讓 Parent 發生一次狀態更新：

1,000 Components
        ↓
Parent State Update
        ↓
       Vue
        ↓
      Update

這裡的問題就不一樣了，這棵已經存在的 Component Tree，在一次 Parent Update 中，實際有多少 Component 被重新 Render？

因為 Parent Update 並不代表所有 Child 都一定重新 Render，所以不能直接假設：

Parent Update
      ↓
1,000 Components
      ↓
1,000 Components Render

也可能實際上是：

Parent Update
      ↓
1,000 Components
      ↓
只有部分 Component Render

這正是 Component Storm Scenario 要量測的地方。

Update Time 還不夠

如果最後只得到一個數字 Update Time = 10 ms，依然不知道這 10ms 到底做了多少 Component 的工作？

因此 Update 階段會再記錄：

Update Time
     +
Component Render Count

其中：

Update Time：這次 Parent Update 花了多少時間
Render Count：這次實際有多少 Component 重新 Render

兩個數字放在一起，才知道 Component Tree 變大後，Update Cost 的增加，是否伴隨更多 Component Render？

如果還需要知道「時間花在哪裡」

到這裡，Update Time 與 Render Count 已經可以回答主要問題，但如果兩個版本之間出現差異，例如：

Version	Vue 3.5.40	Vue 3.6.0-rc.2	△
Update Time	180 ms	150 ms	30 ms

差異的 30ms 需要進一步看 Chrome Performance 的 Flame Chart，確認 實際花在哪條執行路徑。

所以這次 Evidence 可以分成兩個層次：

                 Update
                   │
          ┌────────┴────────┐
          ↓                 ↓
     Update Time       Render Count
     「花多久？」       「更新多少？」
          │                 │
          └────────┬────────┘
                   ↓
              Flame Chart
              「花在哪裡？」

Render Count 是用來回答 Component Storm 的核心問題；Flame Chart 則是在兩個版本出現差異時，用來進一步分析成本來源。