這些 JS 觀念在 React 裡長成什麼樣

1. 對照表：JS 觀念 → React 行為 → 已經寫在哪個檔案

2. 空缺一：JSX 條件渲染的 0 陷阱（最常見的 falsy 事故）

這是把「truthy / falsy」直接踩爆的地方，而且畫面上會冒出一個孤零零的 0，看起來像 UI 壞掉。

// ❌ 購物車是空的時候，畫面上會出現一個「0」
function Cart({ items }) {
  return (
    <div>
      {items.length && <ItemList items={items} />}
    </div>
  );
}

為什麼：&& 運算子不回傳布林值，它回傳的是「決定結果的那個運算元」。

• a. items.length 是 0（falsy）→ && 短路，回傳 0 本身
• b. JSX 拿到 0，而 React 會把數字渲染出來
• c. 畫面上就多了一個「0」

0 && <ItemList />        // 回傳 0        → 畫面出現 0
"" && <ItemList />       // 回傳 ""       → 空字串，看不見（但仍是被渲染的）
null && <ItemList />     // 回傳 null     → 不渲染，安全
undefined && <ItemList />// 回傳 undefined→ 不渲染，安全
NaN && <ItemList />      // 回傳 NaN      → 畫面出現「NaN」

⚠️ 注意 8 個 falsy 值裡有 3 個會被渲染出來（0、NaN、""），另外 5 個安全（false、null、undefined、-0 會顯示 0、0n 會顯示 0）—— 實際上只有 false、null、undefined 是真正安全的。

三種正解

// ✅ 方法 1：把條件變成真正的布林（最推薦，意圖最明確）
{items.length > 0 && <ItemList items={items} />}

// ✅ 方法 2：用雙重否定強制轉成布林
{!!items.length && <ItemList items={items} />}

// ✅ 方法 3：用三元運算子（要處理「否則顯示什麼」的時候用這個）
{items.length ? <ItemList items={items} /> : <EmptyState />}

⚠️ 不要用 Boolean(items.length) && ... —— 能動，但比 > 0 多打好幾個字又沒有比較清楚。

相關聯：本系列第 1 篇

JS-資料型別/JavaScript資料型別總覽-原始型別與物件.md 第 4 節列了完整的 8 個 falsy 值，第 4-b 節解釋了「== 不是用 truthy / falsy 判斷的」。這裡是同一組知識在 JSX 裡的實際事故現場。

3. 空缺二：React 到底會渲染哪些值

這張表沒有任何一篇筆記整理過，但它是理解上面那個陷阱的根本：

記憶口訣：只有 null、undefined、boolean 是「安靜的」，其他原始型別都會現形，物件則直接爆炸。

為什麼 false 不渲染但 0 會

這是 React 刻意的設計取捨：&& 短路在大多數情況下回傳的是 false，如果 false 也被渲染成「false」三個字，那全世界的條件渲染都會壞掉。但 0 是個合法的、使用者可能真的想顯示的數字（例如「庫存：0」），React 沒有立場替你決定要不要顯示它。

所以 0 的陷阱不是 React 的 bug，是 && 運算子的語意 —— 責任在 JS 那一邊。

4. 空缺三：Objects are not valid as a React child

const user = { name: "Abby", age: 20 };
return <div>{user}</div>;
// ❌ Error: Objects are not valid as a React child (found: object with keys {name, age})

為什麼會擋：React 需要把值變成文字節點，但物件的預設 toString() 只會給你 "[object Object]" —— 那對使用者完全沒有意義。與其默默印出一坨沒用的字，React 選擇直接丟錯讓你在開發階段就發現。

最常見的三個觸發情境：

• a. 忘記取欄位 —— {user} 應該是 {user.name}
• b. API 回傳的錯誤物件直接塞進畫面 —— {error} 應該是 {error.message}
• c. 日期物件 —— {new Date()} 會丟錯，要 {date.toLocaleDateString()}

⚠️ Date 是最容易漏的那個，因為它「看起來很像可以直接顯示的東西」。

對照：本系列第 3 篇

JS-資料型別/追問-BigInt取捨-不可變性-與包裝物件.md 第 5 節講的是「原始型別靠臨時包裝物件才有方法」，而這裡是反過來 —— 物件在需要變成原始值的場合（渲染成文字）反而過不去。兩邊都是 ToPrimitive 這條線上的事。

5. 補充：getter / Proxy 算「reactive system」嗎？

算是它的零件，但不等於它。 你自己在 iThome鐵人賽-2026/草稿-useState為什麼沒更新-從getter與Proxy看React的設計選擇.md 的最後（「c. 響應式 ＝ Proxy 嗎？」那段）已經下過結論：

不是。響應式是「效果」，Proxy 是「手段」。

這裡把那句話展開成可檢查的定義。

一個完整的 reactive system 需要三個零件

• a. 攔截（intercept） —— 知道「有人讀了 / 有人寫了這個值」
  這一層才是 getter / setter 與 Proxy 負責的部分。
• b. 依賴收集（dependency tracking） —— 在讀的時候記下「是誰在讀我」
  Vue 叫 track()，它把「目前正在執行的 effect」記進這個屬性的訂閱清單。
• c. 觸發更新（trigger / scheduler） —— 在寫的時候通知剛才記下的那些人
  Vue 叫 trigger()，然後丟進 queueJob 排程。

只有 a 不算 reactive system，那只是「可以攔截」。三個湊齊才是。

各家對照

⚠️ 注意第 1 與第 3 列：同樣是 getter / setter，Vue 2 和 Vue 3 的 ref() 都是 reactive system。所以「用什麼手段攔截」跟「算不算 reactive」是兩回事 —— 差別在有沒有 b 和 c。

React 為什麼三個零件一個都不做

因為它走的是完全不同的路線：pull-based（拉）而不是 push-based（推）。

【push-based：Vue / Solid / Signals】

  你改了 state.count = 1
        │
        ▼
  set trap 被攔截
        │
        ▼
  查訂閱清單：「誰讀過 count ？」→ 找到 [畫面 A, computed B]
        │
        ▼
  只通知這兩個 ── 精準到單一節點，不需要 diff
        │
        ▼
  更新畫面 A 與 computed B


【pull-based：React】

  你呼叫 setCount(1)
        │
        ▼
  React 只知道「有人說變了」，不知道是誰用到它
        │            ← 因為它從來沒攔截過讀取，沒有訂閱清單
        ▼
  把整個元件函式「從頭再跑一次」，產生新的 element 樹
        │
        ▼
  跟上一棵樹做 diff / reconciliation
        │
        ▼
  找出真的不一樣的地方，commit 到 DOM

這條線串起你既有的三篇

• a. 為什麼 React 需要新物件 —— 因為它沒有攔截，只能在 re-render 時用 Object.is 比新舊參考。這就是 frontend-docs/javascript/JS_Core_and_Runtime/比較三兄弟-鬆散等於-嚴格等於-Object-is-與React-Vue的狀態比對.md 講的事。
• b. 為什麼陣列不能 push —— 同上，push 是原地改，參考沒變，Object.is 判定沒變。
• c. 為什麼 useRef 改 .current 不會重繪 —— 因為 ref 連「有人說變了」這個訊號都不發。
• d. 為什麼 Vue 可以直接改 —— 因為 Proxy 攔截得到，所以有訂閱清單可查。

⚠️ 一個容易誤會的新東西：React Compiler

React Compiler v1.0 已於 2025-10-07 正式發布（React Conf 2025）。它會自動幫你插入 memoization，效果上很像「React 變聰明了」，但它不是 reactive system：

• a. 它在編譯期（build time）分析你的程式碼，自動補上等價於 useMemo / useCallback / React.memo 的邏輯
• b. 它沒有在執行期攔截任何讀寫，沒有訂閱清單
• c. React 依然是 pull-based，只是「重跑」的範圍被編譯器縮小了

所以到 2026 年為止，React 官方仍然沒有引入 signals，也沒有 runtime 的 reactivity。這是路線選擇，不是還沒做到。

關聯：frontend-docs/vue/00-ref與reactive-響應式的兩種實作.md 第三節與第四節把 ref()（getter/setter）與 reactive()（Proxy）拆得很清楚，配合這一節的三零件定義讀，兩邊會扣起來。

為什麼 d（getter 與 Proxy）要排在 f（useState 底層）前面

一句話：d 回答「為什麼」，f 回答「怎麼做」，先有動機再看實作才不會卡住。

• a. d 是設計層：它回答「React 為什麼需要你呼叫 setState，不能像 Vue 一樣直接改就好」。答案是 React 刻意不做攔截（見下一節）。
• b. f 是實作層：它回答「你呼叫 setState 之後，Fiber 上的 memoizedState 鏈表發生了什麼」。
• c. 前置知識的門檻差很多：d 只需要「存取器屬性」這一個前置（你在 iThome鐵人賽-2026/Day03-靜態方法-實例方法-存取器屬性-讀懂React原始碼的三行寫法.md 已經寫過）；f 需要 Fiber、單向鏈表、閉包三個前置。
• d. 如果先讀 f，你會一路帶著「所以到底為什麼不能直接改 state 就好」這個疑問看完整篇，那個疑問的答案在 d。

⚠️ 修正：這份順序我第一版把 e、f 寫反了。useState底層 那篇的第四節是「過期閉包（Stale Closure）」，它需要閉包的心智模型當前置，所以應該排在 debounce與useRef 之後。已改正。

6. 延伸練習

• a. LeetCode 2704. To Be Or Not To Be —— 相等判斷
• b. LeetCode 2705. Compact Object —— falsy 清單實戰
• c. LeetCode 2635. Apply Transform Over Each Element in Array —— 自己實作 map，對應 JSX 清單渲染
• d. LeetCode 2625. Flatten Deeply Nested Array —— 不可變思維

7. 參考來源

所有 URL 於 2026-09-05 查閱。

• a. React 官方文件 —— Conditional Rendering（含 && 的 0 陷阱官方說明）
• b. React 官方文件 —— Rendering Lists
• c. React 官方文件 —— Updating Objects in State
• d. React 官方文件 —— Keeping Components Pure
• e. MDN —— 邏輯 AND (&&)（「回傳運算元本身而不是布林」的規範行為）
• f. MDN —— Glossary: Falsy
• g. MDN —— Object.is()
• h. MDN —— Proxy ｜ Object.defineProperty()（Vue 2 的攔截手段）
• i. Vue 官方文件 —— Reactivity in Depth（track / trigger 與依賴收集）
• j. React 官方部落格 —— React Compiler v1.0（2025-10-07 發布，確認它是編譯期 memoization 而非 runtime reactivity）
• k. React 官方文件 —— useRef（改 .current 不觸發 re-render）