大家好，我卡頌。

前端界有句玩笑話 —— 「React 一點都不 react，Solid 才應該叫 React」。

作為一款「借鑒了很多 React 特性」的前端框架，截止目前，Solid已經有 29.6kstar。顯然，他已經得到了社區(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ā)」這種工作模式的基石。

如何實現局部思考

假設項目中有如下代碼，你能保證結果是true么：

const obj = {}
someFunction(obj)

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

要想知道結果，必須看someFunction函數的內部實現。如果項目中大量充斥了上面這樣的代碼，對可讀性、可維護性簡直是災難。

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

• 單向數據流
• 讀寫分離
• 顯式突變

1. 組件隔離

單向數據流

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

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

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

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

讀寫分離

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

考慮如下Solid代碼，SomeComponent通過title()讀取值，通過setTitle修改值。這種分離使得我們可以更好地理解狀態(tài)何時變化。

// [讀, 寫]
const [title, setTitle] = createSignal("title");

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

// 現在`SomeComponent`可以更新title
<SomeComponent title={title()} updateTitle={setTitle} />

在Svelte中，狀態(tài)（或者叫signal）只能「按值傳遞」，所以下面SomeComponent即使接收title作為props，也無法直接修改他。

要修改他，需要執(zhí)行updateTitle方法（方法內部閉包中的title是signal，可以響應更新）。這也是一種「讀寫分離」的實現。

let title = $state("title")

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

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

顯式突變

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

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

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

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

組件隔離

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

總結

如果你覺得以上的介紹一點技術含量都沒有，那是再自然不過的事。因為這些原則都是React最基本的使用規(guī)范。

本文存在的意義，是闡述一個觀點 —— 這些規(guī)范之所以存在，是為了共同實現「局部思考」的理念。而這一理念，才是前端框架可維護性、可讀性的來源。

按照這個思路去思考，就能明白很多React特性的用意，比如：

• 為什么函數組件替代了類組件。
• 為什么會出現useEffect這個Hook。
• 為什么ref不能跨函數組件傳遞。

這些特性的背后，都體現了「局部思考」的理念。

參考資料

[1]Thinking Locally with Signals:https://dev.to/this-is-learning/thinking-locally-with-signals-3b7h。