React 的核心設計前提是建立在一個重要假設之上:『資料與元件狀態的變化無法事先預測』。基於此假設,React 必須持續透過 Virtual DOM 的機制,來比對新舊 UI 狀態之間的差異,藉此決定哪些地方需要重新渲染,這個假設帶來了額外的效能成本與複雜度。
但如果,我們推翻這固有的假設呢?如果資料的變化本來就可以精確地被觀測和追蹤,我們還需要使用 V-DOM 進行比對?這就是 Signal 提出的新視角:資料本身具備觀測性,我們可以透過精細的 side effects 直接處理相關 UI 變動,跳脫 V-DOM 的限制。在此系列文章中,我將帶你一步一步認識 Signal 的核心概念。
引言 上一篇我們已經完成一個具備訂閱功能的 Signal 核心,這一篇我們來實作 Effect,讓每個依賴項都能自動去追蹤,順利讓原本靜態的圖能具有響應性的動起...
快速回顧 還記得這張圖嗎?上一篇我們透過實作 Registry 這層抽象,讓我們能夠有不同資料結構處理 Effect 排程的選擇權,那你一定會想... 為什麼需...
回顧前情提要 graph.ts:Node{ kind, deps, subs }、link/unlink、withObserver/track(沿用實作 E...
前情提要 承接前面幾篇的內容(signal, effect, computed),我們把「副作用的執行時機」做得更可控: 多次 set 合併 → 同一輪只重跑...
為什麼框架會影響你怎麼用 signals? 簡單回答就是 生命週期,但在脆上有批 React 仔永遠當它不存在的在賣課,確實也蠻擔心的,但你深入到一定的程度,就...
本文目標 把前面實作過的 signals/computed 以 不撕裂(tear-free) 的方式接進 React 18 Concurrent 模式關鍵:快照...
從未消失的生命週期 從本系列的開頭講解,一直到現在的實作,都是圍繞著「資料層的生命週期」:資料如何被讀取、失效、重算、與何時觸發副作用。 這並不衝突於框架本身的...
快速回顧 這篇接續上一篇的結尾,讓我們來透過實際的範例,理解要怎麼互補使用。 Effect 清理策略 首先,我們先來釐清主要的概念: 我們的 effect(c...
本篇目標 理解為什麼會 撕裂(tearing),如何保證 tear-free 訂閱 keys 重掛 下如何避免殘留訂閱 / 計算節點 在 Transitio...
快速導覽 上一篇,我們介紹了: 為什麼會 撕裂(tearing),如何保證 tear-free 訂閱 keys 重掛 下如何避免殘留訂閱 / 計算節點 在 T...