## 0. 從模型說起

![圖1](http://img-hxy021.didistatic.com/static/way/do1_bvBBjgknQjd26MnRrwvs)

**原生JS/jQuery** 這時候開發者需要手動處理 **Bind**、**Change** 和 **Update**，jQuery 相比原生 JS，簡化了操作，遮蔽了瀏覽器的相容性。

**三大框架** 這時候開發者只需處理 **Bind** 和 **Change**，框架自動完成 **Update**。框架使用一套高效的 diff 演算法最小化更新 DOM，因此除了簡化開發者工作，還帶來了前端效能的提升。

## 1. 元件思想

除此之外，框架另一個突出貢獻是引入了 **元件** 思想，這使我們能將一個複雜的應用拆成多個元件逐個擊破，還使我們能用一套基礎元件組合出各種各樣的應用，以高效的響應業務需求。

![圖2](http://img-hxy021.didistatic.com/static/way/do1_azv4eNGqLqRAdIAGqk7K)

但是在大型應用中，這種方式又出現 **2個嚴重的問題**。

![圖3](http://img-hxy021.didistatic.com/static/way/do1_xmBL7pvVMGLFr9SivcqW)

跨元件資料傳遞** 在單向資料流中，**Props down & Event up**，跨元件的資料傳遞非常困難，如上圖的，中間2個元件即使不關注資料，也必須寫上相關程式碼讓資料傳下來。聯想到現實中，我們說的組織層級過多導致流程冗雜，也是類似的道理。

![圖4](http://img-hxy021.didistatic.com/static/way/do1_N2GJFdEJFew4T5I5zTMs)

**意外資料修改** JS 的資料型別和 Java 類似，除了少數幾個基礎型別是值，其他的都是 **引用**，因此在某個子元件裡的資料修改，很容易影響到其他地方。儘管框架一再警告 **props** 應該看作只讀的，但受制於語言特性，框架無法阻止意外的修改。

從開發者角度，我們也希望能 **在一個地方就看到整個應用的狀態**，而不是深入到各個元件裡去檢視。

## 2. 狀態管理

對於跨元件資料共享問題，一個自然的想法是：為啥不寫一個公共的模組，把共享的變數都放到裡面呢，之前寫後端也是這樣的呀？

前端還真不能這麼幹！根本原因在於我們要依賴框架的自動 **Update** 能力（第一張圖），React 中 **有且僅有兩種情況會觸發介面更新**：

- state 變化（`setState`）
- context 變化（Redux）

（說 `forceUpdate` 的，看我眼神……）

於是 Redux 登場，理想情況下，資料流會被規整成下圖那樣：

![圖5](http://img-hxy021.didistatic.com/static/way/do1_wbNpqxDYvCbM5utpYhJC)

但是 Redux 也不是免費的，它帶來兩個我一直耿耿於懷的問題：

**元件不能任意組合** 元件連線 Redux 以後，即喪失了封閉性，如果頁面上出現這樣一個元件的兩個例項，那這兩個例項的狀態就會互相影響。

**割裂的邏輯** 強行將邏輯拆成 **action** 和 **reducer**，一個功能要改3處程式碼，怎麼看怎麼蠢。

## 3. Maybe hooks？

較早前就聽過 **hooks**，當時並不以為意，想著無非是給函式元件注入狀態而已。資料和方法繫結，扒著指頭數也就3種方式：

- 模組
- 類
- 閉包

類就挺直觀的呀，幹嗎要要用閉包這種 tricky 方式去做？直到最近讀文件，才發現這可能就是我一直心心念的 **既要有清晰的資料流，又不割裂邏輯** 的實現方式，抄 [一段程式碼](https://reactjs.org/docs/hooks-effect.html#tip-use-multiple-effects-to-separate-concerns) 感受感受：

```js
class FriendStatusWithCounter extends React.Component {
  constructor(props) {
    super(props);
    this.state = { count: 0, isOnline: null };
    this.handleStatusChange = this.handleStatusChange.bind(this);
  }

componentDidMount() {
    document.title = `You clicked ${this.state.count} times`;
    ChatAPI.subscribeToFriendStatus(
      this.props.friend.id,
      this.handleStatusChange
    );
  }

componentDidUpdate() {
    document.title = `You clicked ${this.state.count} times`;
  }

componentWillUnmount() {
    ChatAPI.unsubscribeFromFriendStatus(
      this.props.friend.id,
      this.handleStatusChange
    );
  }

handleStatusChange(status) {
    this.setState({
      isOnline: status.isOnline
    });
  }
  // ...
```

```js
function FriendStatusWithCounter(props) {
  const [count, setCount] = useState(0);
  useEffect(() => {
    document.title = `You clicked ${count} times`;
  });

const [isOnline, setIsOnline] = useState(null);
  useEffect(() => {
    function handleStatusChange(status) {
      setIsOnline(status.isOnline);
    }

ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange);
    return () => {
      ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange);
    };
  });
  // ...
}
```

看，hooks 能不受 class 元件生命週期鉤子的限制，將邏輯相關的程式碼集中到一起了！

## 4. 其他

**state 裡該放什麼資料** 由於我們使用 state 的本質是利用框架的自動更新 DOM 的能力，因此 state 裡只需放 **介面相關** 的資料。

**Redux 裡該放什麼資料** Redux 的職責更多是資料管理，開發實踐中，隨業務迭代介面資料變動會比較頻繁，適宜放 Redux 中；另外跨元件共享的資料也要放 Redux 中。總結起來就是 **介面相關 && (服務端的 || 共享的)** 應該放 Redux 中。

**那豈不是和資料全貌相差太大了** 只把介面相關的資料放 state 和 redux 裡，會不會與業務資料全貌相差太大了呢？我認為不會，在後端“讀寫分離”的實踐中，一般做法只是將查詢和寫入的服務放到不同的例項上，而更進一步的做法是 **查詢用的表和寫入用的表都是不一樣的**！state 和 Redux 就是類似這樣的讀模型；介面無關的資料，完全可以再放到一個公共模組裡。

作者：楊少軍
- [滴滴雲全線標準型雲伺服器限時特惠](https://www.didiyun.com/?channel=14816)
- [新購雲服務1月5折 3月4折 6月低至3折](https://www.didiyun.com/?channel=14816)
- [註冊即送新手大禮包](https://www.didiyun.com/?channel=14816)

前端演進思考

相關文章