Solid 作者從 React 中學到最重要的是什么？
大家好，我卡頌。
前端界有句玩笑話 —— 「React 一點都不 react，Solid 才應該叫 React」。
作為一款「借鑒了很多 React 特性」的前端框架，截止目前，Solid已經(jīng)有 29.6kstar。顯然，他已經(jīng)得到了社區(qū)的認可。
前段時間，Solid的作者「Ryan Carniato」在博文Thinking Locally with Signals[1]中提到 —— Solid從React中學到的最重要的東西，不是JSX、虛擬DOM，而是一個被稱為「局部思考」（Locality of Thinking）的概念。
本文就來聊聊這個對前端開發(fā)影響深遠的理念。
局部思考是什么？
當我們新入職一家公司，在熟悉項目代碼階段，領導通常會分配給我們一些小需求，幫助我們快速熟悉項目代碼。
這個過程是如此自然，以至于我們都忽視了一個重要問題 —— 為什么在一個龐大的項目代碼庫中，即使不熟悉代碼，也能輕松修改一些小功能？
答案是 —— 「局部思考」理念在發(fā)揮作用。
「局部思考」是指你可以不看其他代碼，只通過一個組件的代碼就能理解它的行為。這種思考方式對代碼的可維護性和可讀性有著重大影響。
首先，在大型項目中，代碼的「可維護性」至關重要。如果每次修改都需要理解整個代碼庫，那么這個項目可能會很快變得難以維護。
其次，從「可讀性」的角度來看，如果代碼的可讀性好，那么新的開發(fā)人員可以更快地理解和開始他們的工作。
通過「局部思考」，可以使代碼更易讀、可維護性更高。試想，這不正是「使用框架開發(fā)」相比于「使用 jQuery 開發(fā)」的優(yōu)勢么？至于框架的其他特性（比如虛擬DOM、細粒度更新、Hooks...）都是在「局部思考」的基礎上發(fā)展出來的。
可以說，「局部思考」是「框架開發(fā)」這種工作模式的基石。
如何實現(xiàn)局部思考
假設項目中有如下代碼，你能保證結果是true么：
const obj = {}
someFunction(obj)
// 結果是 true 么？
console.log(obj.value === undefined)要想知道結果，必須看someFunction函數(shù)的內部實現(xiàn)。如果項目中大量充斥了上面這樣的代碼，對可讀性、可維護性簡直是災難。
「局部思考」理念的提出就是為了解決上述問題。要實現(xiàn)「局部思考」，有四個重要因素：
- 單向數(shù)據(jù)流
- 讀寫分離
- 顯式突變
- 組件隔離
單向數(shù)據(jù)流
數(shù)據(jù)應該只在一個方向上流動。這樣可以保證數(shù)據(jù)的來源和使用是一致的，使得代碼行為更可預測，減小了出現(xiàn)bug的可能性。
考慮如下Solid代碼，數(shù)據(jù)只從父組件流向子組件。子組件只讀取數(shù)據(jù)，而不能改變它：
// 父組件內
const [count, setCount] = createSignal(0);
<ChildComponent count={count()} />
// 子組件內
const ChildComponent = ({ count }) => {
// count是只讀的
return <div>{count}</div>
}讀寫分離
讀取數(shù)據(jù)和修改數(shù)據(jù)應該是兩個獨立的操作。這樣可以降低代碼的復雜度，使得閱讀和理解代碼更簡單。
考慮如下Solid代碼，SomeComponent通過title()讀取值，通過setTitle修改值。這種分離使得我們可以更好地理解狀態(tài)何時變化。
// [讀, 寫]
const [title, setTitle] = createSignal("title");
// `SomeComponent`不能改變`title`
<SomeComponent title={title()} />
// 現(xiàn)在`SomeComponent`可以更新title
<SomeComponent title={title()} updateTitle={setTitle} />在Svelte中，狀態(tài)（或者叫signal）只能「按值傳遞」，所以下面SomeComponent即使接收title作為props，也無法直接修改他。
要修改他，需要執(zhí)行updateTitle方法（方法內部閉包中的title是signal，可以響應更新）。這也是一種「讀寫分離」的實現(xiàn)。
let title = $state("title")
// `SomeComponent`不能改變`title`
<SomeComponent title={title} />
// 現(xiàn)在`SomeComponent`可以更新title
<SomeComponent title={title} updateTitle={(v) => title = v} />顯式突變
所有的數(shù)據(jù)變化應該是顯式的，而不是在背后默默發(fā)生。這樣更容易跟蹤數(shù)據(jù)的變化。考慮如下Solid代碼：
// 定義狀態(tài)
const [count, setCount] = createSignal(0);
// 顯式改變狀態(tài)
setCount(count() + 1);是不是一下就想到了React中的useState呢？沒錯，其實不止是useState，在ClassComponent的this.setState也是遵循同樣的原則。
組件隔離
每個組件應該只關心自己的狀態(tài)和邏輯，而不是其他組件的。這樣可以保證組件之間的獨立性，降低耦合度，使得代碼更易于維護。
總結
如果你覺得以上的介紹一點技術含量都沒有，那是再自然不過的事。因為這些原則都是React最基本的使用規(guī)范。
本文存在的意義，是闡述一個觀點 —— 這些規(guī)范之所以存在，是為了共同實現(xiàn)「局部思考」的理念。而這一理念，才是前端框架可維護性、可讀性的來源。
按照這個思路去思考，就能明白很多React特性的用意，比如：
- 為什么函數(shù)組件替代了類組件。
- 為什么會出現(xiàn)useEffect這個Hook。
- 為什么ref不能跨函數(shù)組件傳遞。
這些特性的背后，都體現(xiàn)了「局部思考」的理念。
參考資料
[1]Thinking Locally with Signals:https://dev.to/this-is-learning/thinking-locally-with-signals-3b7h。
