引言

React 的核心設計，是建立在一個重要假設之上：「資料與元件狀態的變化無法事先預測」。基於這個假設，React 必須持續透過 Virtual DOM（虛擬 DOM）機制，來反覆比對新舊 UI 狀態間的差異，藉此決定哪些部分需要重新渲染。

然而，這種設計方式也帶來了額外的效能成本與複雜度，尤其在大型專案中，這樣的問題更為明顯。

但如果，我們從根本上重新推翻這個假設呢？
如果資料的變化原本就能精確地被觀測與追蹤，我們還需要透過 Virtual DOM 進行比對嗎？

這正是 Signal 與 Fine-grained Reactivity 架構所提出的核心觀點：資料本身具備內建的可觀測性（Observability），我們可以透過精細的 Side Effects 直接處理對應的 UI 變動，完全跳脫 Virtual DOM 所帶來的效能損耗與限制。

這個觀點也呼應了 Solid.js 作者 Ryan Carniato 在分享框架設計哲學時的核心精神。也許在 2012 年的技術背景下，React 的假設看似合理而穩固，但隨著後續框架技術的發展，例如 Svelte 的崛起，確實給整個前端社群帶來了深刻的啟發：Virtual DOM 的概念可能只是過渡性的解決方案，而真正更完善、更本質的解法，很可能就是 Fine-grained Reactivity。

在這個系列文章中，我將帶你一步步深入了解 Signal 的核心概念、運作原理，並透過實務範例與 React 的整合方式，展示如何打造出一個更輕量、更精準、更高效的 React 應用架構。

什麼是 Signal？

你可以把 Signal 想成一個「盒子」或「容器」，它裡面裝著一個值。
這個盒子有幾個關鍵特性：

• 讀取值：你可以隨時讀取盒子裡面的值。
• 修改值：如果 Signal 是可寫的，你可以修改盒子裡面的值。
• 自動通知依賴者：最重要的是，當盒子裡面的值改變時，所有依賴這個 Signal 的部分（例如，你的 UI 元素、其他計算屬性等）都會被自動且高效地通知，然後它們會根據新的值進行更新。

舉個簡單的例子：

const count = signal(0);

// 當 count 改變時，這個 Effect 自動更新
createEffect(() => {
  console.log("count：", count.get());
});

// 更新 Signal
count.set(1);  // console: count 更新為：1
count.set(2);  // console: count 更新為：2

比起 React 中常見的 useState，Signal 的最大優勢在於提供更細緻（fine-grained）的狀態追蹤，進而大幅減少無意義的 UI 重渲染，提升效能。後續章節，我們將進一步詳細介紹 Signal 的內部運作機制，並說明如何透過 Signal 來優化你的 React 應用。

結語

Signal 所提出的這種觀察資料本質的方法，將帶我們重新探索 React 開發的可能性。

這系列的文章靈感來自於我自己開發的開源專案--segnale-react，有鑑於 TC39 已經將 Signal 列入日後的標準(雖然還在Stage-1)，也讓 Signal 這個概念有比較熱的討論度，這系列文章會探討前端框架式怎麼處理用戶響應(Recativity)的。

跟著閱讀，我們會一步一步的建構一個 Signal 的狀態管理系統，並示範如何導入主流框架中應用，還有探討各個框架狀態管理系統上的取捨，是一種比較進階的探討，當然還是會稍微講解一些 JavaScript 基礎，當然不可能在基礎上著墨太多，還請讀者多多包涵。

在下一篇文章中，我們將進一步探討 Signal 內部運作的核心原理，從而更清楚理解為什麼這樣的架構能顯著改善 React 應用的效能，敬請期待！