摘要：本周精讀內(nèi)容是重新思考。數(shù)據(jù)流對數(shù)據(jù)緩存，性能優(yōu)化，開發(fā)體驗(yàn)優(yōu)化都有進(jìn)一步施展的空間，擁抱插件生態(tài)是一個(gè)良好的發(fā)展方向。

本周精讀內(nèi)容是 《重新思考 Redux》。

《重新思考 Redux》是 rematch 作者 Shawn McKay 寫的一篇干貨軟文。

dva 之后，有許多基于 redux 的狀態(tài)管理框架，但大部分都很局限，甚至是倒退。但直到看到了 rematch，總算覺得 redux 社區(qū)又進(jìn)了一步。

這篇文章的寶貴之處在于，拋開 Mobx、RXjs 概念，僅針對 redux 做深入的重新思考，對大部分還在使用 redux 的工程場景非常有幫助。

比較新穎的是，作者給出一個(gè)公式，評價(jià)一個(gè)框架或工具的質(zhì)量：

工具質(zhì)量 = 工具節(jié)省的時(shí)間/使用工具消耗的時(shí)間

如果這樣評估原生的 redux，我們會(huì)發(fā)現(xiàn)，使用 redux 需要額外花費(fèi)的時(shí)間可能超過了其節(jié)省下來的時(shí)間，從這個(gè)角度看，redux 是會(huì)降低工作效率的。

但 redux 的數(shù)據(jù)管理思想是正確的，復(fù)雜的前端項(xiàng)目也確實(shí)需要這種理念，為了更有效率的使用 redux，我們需要使用基于 redux 的框架。作者從 6 個(gè)角度闡述了基于 redux 的框架需要解決什么問題。

redux 初始化代碼涉及的概念比較多，比如 compose thunk 等等，同時(shí)將 reducer、initialState、middlewares 這三個(gè)重要概念拆分成了函數(shù)方式調(diào)用，而不是更容易接受的配置方式：

const store = preloadedState => {
  return createStore(
    rootReducer,
    preloadedState,
    compose(applyMiddleware(thunk, api), DevTools.instrument())
  );
};

如果換成配置方式，理解成本會(huì)降低不少：

const store = new Redux.Store({
  instialState: {},
  reducers: { count },
  middlewares: [api, devTools]
});

筆者注：redux 的初始化方式非常函數(shù)式，而下面的配置方式就更面向?qū)ο笠恍?。相比之下，還是面向?qū)ο蟮姆绞礁美斫?，畢?store 是一個(gè)對象。instialState 也存在同樣問題，相比顯示申明，將 preloadedState 作為函數(shù)入?yún)⒕捅容^抽象了，同時(shí) redux 對初始 state 的賦值也比較隱蔽，createStore 時(shí)統(tǒng)一賦值比較別扭，因?yàn)?reducers 是分散的，如果在 reducers 中賦值，要利用 es 的默認(rèn)參數(shù)特性，看起來更像業(yè)務(wù)思考，而不是 redux 提供的能力。

redux 的 reducer 粒度太大，不但導(dǎo)致函數(shù)內(nèi)手動(dòng)匹配 type，還帶來了 type、payload 等理解成本：

const countReducer = (state, action) => {
  switch (action.type) {
    case INCREMENT:
      return state + action.payload;
    case DECREMENT:
      return state - action.payload;
    default:
      return state;
  }
};

如果用配置的方式設(shè)置 reducers，就像定義一個(gè)對象一樣，會(huì)更清晰：

const countReducer = {
  INCREMENT: (state, action) => state + action.payload,
  DECREMENT: (state, action) => state - action.payload
};

redux 支持動(dòng)態(tài)數(shù)據(jù)還是挺費(fèi)勁的，需要理解高階函數(shù)，理解中間件的使用方式，否則你不會(huì)知道為什么這樣寫是對的：

const incrementAsync = count => async dispatch => {
  await delay();
  dispatch(increment(count));
};

為什么不抹掉理解成本，直接允許 async 類型的 action 呢？

const incrementAsync = async count => {
  await delay();
  dispatch(increment(count));
};

筆者注：我們發(fā)現(xiàn) rematch 的方式，dispatch 是 import 進(jìn)來的（全局變量），而 redux 的 dispatch 是注入進(jìn)來的，乍一看似乎 redux 更合理，但其實(shí)我更推崇 rematch 的方案。經(jīng)過長期實(shí)踐，組件最好不要使用數(shù)據(jù)流，項(xiàng)目的數(shù)據(jù)流只用一個(gè)實(shí)例完全夠用了，全局 dispatch 的設(shè)計(jì)其實(shí)更合理，而注入 dispatch 的設(shè)計(jì)看似追求技術(shù)極致，但忽略了業(yè)務(wù)使用場景，導(dǎo)致畫蛇添足，增加了不必要的麻煩。

redux 抽象的 action 與 reducer 的指責(zé)很清晰，action 負(fù)責(zé)改 store 以外所有事，而 reducer 負(fù)責(zé)改 store，偶爾用來做數(shù)據(jù)處理。這種概念其實(shí)比較模糊，因?yàn)橥磺宄?shù)據(jù)處理放在 action 還是 reducer 里，同時(shí)過于簡單的 reducer 又要寫 action 與之匹配，感覺過于形式化，而且繁瑣。

重新考慮這個(gè)問題，我們只有兩類 action：reducer action 與 effect action。

reducer action：改變 store。

effect action：處理異步場景，能調(diào)用其他 action，不能修改 store。

同步的場景，一個(gè) reducer 函數(shù)就能處理，只有異步場景需要 effect action 處理掉異步部分，同步部分依然交給 reducer 函數(shù)，這兩種 action 職責(zé)更清晰。

不要在用一個(gè)文件存儲(chǔ) Action 類型了，const ACTION_ONE = "ACTION_ONE" 其實(shí)重復(fù)寫了一遍字符串，直接用對象的 key 表示 action 的值，再加上 store 的 name 為前綴保證唯一性即可。

同時(shí) redux 建議使用 payload key 來傳值，那為什么不強(qiáng)制使用 payload 作為入?yún)?，而要通過 action.payload 取值呢？直接使用 payload 不但視覺上減少代碼數(shù)量，容易理解，同時(shí)也強(qiáng)制約束了代碼風(fēng)格，讓建議真正落地。

redux 調(diào)用 action 比較繁瑣，使用 dispatch 或者將 reducer 經(jīng)過 ActionCreator 函數(shù)包裝。為什么不直接給 reducer 自動(dòng)包裝 ActionCreator 呢？減少樣板代碼，讓每一行代碼都有業(yè)務(wù)含義。

最后作者給出了一個(gè) rematch 完整的例子：

import { init, dispatch } from "@rematch/core";
import delay from "./makeMeWait";

const count = {
  state: 0,
  reducers: {
    increment: (state, payload) => state + payload,
    decrement: (state, payload) => state - payload
  },
  effects: {
    async incrementAsync(payload) {
      await delay();
      this.increment(payload);
    }
  }
};

const store = init({
  models: { count }
});

dispatch.count.incrementAsync(1);

我覺得本文基本上把 redux 存在的工程問題分析透徹了，同時(shí)還給出了一套非常好的實(shí)現(xiàn)。

首先是直接使用 payload 而不是整個(gè) action 作為入?yún)?，加?qiáng)了約束同時(shí)簡化代碼復(fù)雜度:

increment: (state, payload) => state + payload;

其次使用 async 在 effects 函數(shù)中，使用 this.increment 函數(shù)調(diào)用方式，取代 put({type: "increment"})（dva），在 typescript 中擁有了類型支持，不但可以用自動(dòng)跳轉(zhuǎn)代替字符串搜索，還能校驗(yàn)參數(shù)類型，在 redux 框架中非常難得。

最后在 dispatch 函數(shù)，也提供了兩種調(diào)用方式：

dispatch({ type: "count/increment", payload: 1 });
dispatch.count.increment(1);

如果為了更好的類型支持，或者屏蔽 payload 概念，可以使用第二種方案，再一次簡化 redux 概念。

rematch 將常用的 reselect、persist、immer 等都集成為了插件，相對比較強(qiáng)化插件生態(tài)的概念。數(shù)據(jù)流對數(shù)據(jù)緩存，性能優(yōu)化，開發(fā)體驗(yàn)優(yōu)化都有進(jìn)一步施展的空間，擁抱插件生態(tài)是一個(gè)良好的發(fā)展方向。

比如 rematch-immer 插件，可以用 mutable 的方式修改 store：

const count = {
  state: 0,
  reducers: {
    add(state) {
      state += 1;
      return state;
    }
  }
};

但是當(dāng) state 為非對象時(shí)，immer 將不起作用，所以最好能養(yǎng)成 return state 的習(xí)慣。

最后說一點(diǎn)瑕疵的地方，reducers 申明與調(diào)用參數(shù)不一致。

比如下面的 reducers：

const count = {
  state: 0,
  reducers: {
    increment: (state, payload) => state + payload,
    decrement: (state, payload) => state - payload
  },
  effects: {
    async incrementAsync(payload) {
      await delay();
      this.increment(payload);
    }
  }
};

定義時(shí) increment 是兩個(gè)參數(shù)，而 incrementAsync 調(diào)用它時(shí)，只有一個(gè)參數(shù)，這樣可能造成一些誤導(dǎo)，筆者建議保持參數(shù)對應(yīng)關(guān)系，將 state 放在 this 中：

const count = {
  state: 0,
  reducers: {
    increment: payload => this.state + payload,
    decrement: payload => this.state - payload
  },
  effects: {
    async incrementAsync(payload) {
      await delay();
      this.increment(payload);
    }
  }
};

當(dāng)然 rematch 的方式保持了函數(shù)的無副作性質(zhì)，可以看出是做了一些取舍。

重復(fù)一下作者提出工具質(zhì)量的公式：

工具質(zhì)量 = 工具節(jié)省的時(shí)間/使用工具消耗的時(shí)間

如果一個(gè)工具能節(jié)省開發(fā)時(shí)間，但本身帶來了很大使用成本，在想清楚如何減少使用成本之前，不要急著用在項(xiàng)目中，這是我得到的最大啟發(fā)。

最后感謝 rematch 作者精益求精的精神，給 redux 帶來進(jìn)一步的極致優(yōu)化。

討論地址是：精讀《重新思考 Redux》 · Issue #83 · dt-fe/weekly

如果你想?yún)⑴c討論，請點(diǎn)擊這里，每周都有新的主題，周末或周一發(fā)布。