大家好，我卡頌。

前端界有句玩笑話 —— 「React 一點都不 react，Solid 才應(yīng)該叫 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ā)影響深遠的理念。

局部思考是什么？

當我們新入職一家公司，在熟悉項目代碼階段，領(lǐng)導(dǎo)通常會分配給我們一些小需求，幫助我們快速熟悉項目代碼。

這個過程是如此自然，以至于我們都忽視了一個重要問題 —— 為什么在一個龐大的項目代碼庫中，即使不熟悉代碼，也能輕松修改一些小功能？

答案是 —— 「局部思考」理念在發(fā)揮作用。

「局部思考」是指你可以不看其他代碼，只通過一個組件的代碼就能理解它的行為。這種思考方式對代碼的可維護性和可讀性有著重大影響。

首先，在大型項目中，代碼的「可維護性」至關(guān)重要。如果每次修改都需要理解整個代碼庫，那么這個項目可能會很快變得難以維護。

其次，從「可讀性」的角度來看，如果代碼的可讀性好，那么新的開發(fā)人員可以更快地理解和開始他們的工作。

通過「局部思考」，可以使代碼更易讀、可維護性更高。試想，這不正是「使用框架開發(fā)」相比于「使用 jQuery 開發(fā)」的優(yōu)勢么？至于框架的其他特性（比如虛擬DOM、細粒度更新、Hooks...）都是在「局部思考」的基礎(chǔ)上發(fā)展出來的。

可以說，「局部思考」是「框架開發(fā)」這種工作模式的基石。

如何實現(xiàn)局部思考

假設(shè)項目中有如下代碼，你能保證結(jié)果是true么：

const obj = {}
someFunction(obj)

// 結(jié)果是 true 么？
console.log(obj.value === undefined)

要想知道結(jié)果，必須看someFunction函數(shù)的內(nèi)部實現(xiàn)。如果項目中大量充斥了上面這樣的代碼，對可讀性、可維護性簡直是災(zāi)難。

「局部思考」理念的提出就是為了解決上述問題。要實現(xiàn)「局部思考」，有四個重要因素：

• 單向數(shù)據(jù)流
• 讀寫分離
• 顯式突變

1. 組件隔離

單向數(shù)據(jù)流

數(shù)據(jù)應(yīng)該只在一個方向上流動。這樣可以保證數(shù)據(jù)的來源和使用是一致的，使得代碼行為更可預(yù)測，減小了出現(xiàn)bug的可能性。

考慮如下Solid代碼，數(shù)據(jù)只從父組件流向子組件。子組件只讀取數(shù)據(jù)，而不能改變它：

// 父組件內(nèi)
const [count, setCount] = createSignal(0);
<ChildComponent count={count()} />

// 子組件內(nèi)
const ChildComponent = ({ count }) => {
  // count是只讀的
  return <div>{count}</div>
}

讀寫分離

讀取數(shù)據(jù)和修改數(shù)據(jù)應(yīng)該是兩個獨立的操作。這樣可以降低代碼的復(fù)雜度，使得閱讀和理解代碼更簡單。

考慮如下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方法（方法內(nèi)部閉包中的title是signal，可以響應(yīng)更新）。這也是一種「讀寫分離」的實現(xiàn)。

let title = $state("title")

// `SomeComponent`不能改變`title`
<SomeComponent title={title} />

// 現(xiàn)在`SomeComponent`可以更新title
<SomeComponent title={title} updateTitle={(v) => title = v} />

顯式突變

所有的數(shù)據(jù)變化應(yīng)該是顯式的，而不是在背后默默發(fā)生。這樣更容易跟蹤數(shù)據(jù)的變化。考慮如下Solid代碼：

// 定義狀態(tài)
const [count, setCount] = createSignal(0);

// 顯式改變狀態(tài)
setCount(count() + 1);

是不是一下就想到了React中的useState呢？沒錯，其實不止是useState，在ClassComponent的this.setState也是遵循同樣的原則。

組件隔離

每個組件應(yīng)該只關(guān)心自己的狀態(tài)和邏輯，而不是其他組件的。這樣可以保證組件之間的獨立性，降低耦合度，使得代碼更易于維護。

總結(jié)

如果你覺得以上的介紹一點技術(shù)含量都沒有，那是再自然不過的事。因為這些原則都是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。