精读《从新思考 Redux》

本周精读内容是 《从新思考 Redux》。

1 引言

《从新思考 Redux》是 rematch 做者 Shawn McKay 写的一篇干货软文。

dva 以后，有许多基于 redux 的状态管理框架，但大部分都很局限，甚至是倒退。但直到看到了 rematch，总算以为 redux 社区又进了一步。

这篇文章的宝贵之处在于，抛开 Mobx、RXjs 概念，仅针对 redux 作深刻的从新思考，对大部分还在使用 redux 的工程场景很是有帮助。

2 概述

比较新颖的是，做者给出一个公式，评价一个框架或工具的质量：

工具质量 = 工具节省的时间/使用工具消耗的时间

若是这样评估原生的 redux，咱们会发现，使用 redux 须要额外花费的时间可能超过了其节省下来的时间，从这个角度看，redux 是会下降工做效率的。

但 redux 的数据管理思想是正确的，复杂的前端项目也确实须要这种理念，为了更有效率的使用 redux，咱们须要使用基于 redux 的框架。做者从 6 个角度阐述了基于 redux 的框架须要解决什么问题。

简化初始化

redux 初始化代码涉及的概念比较多，好比 compose thunk 等等，同时将 reducer、initialState、middlewares 这三个重要概念拆分红了函数方式调用，而不是更容易接受的配置方式：

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

若是换成配置方式，理解成本会下降很多：

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

笔者注：redux 的初始化方式很是函数式，而下面的配置方式就更面向对象一些。相比之下，仍是面向对象的方式更好理解，毕竟 store 是一个对象。 instialState 也存在一样问题，相比显示申明，将 preloadedState 做为函数入参就比较抽象了，同时 redux 对初始 state 的赋值也比较隐蔽， createStore 时统一赋值比较别扭，由于 reducers 是分散的，若是在 reducers 中赋值，要利用 es 的默认参数特性，看起来更像业务思考，而不是 redux 提供的能力。

简化 Reducers

redux 的 reducer 粒度太大，不但致使函数内手动匹配 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;
  }
};

若是用配置的方式设置 reducers，就像定义一个对象同样，会更清晰：

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

支持 async/await

redux 支持动态数据仍是挺费劲的，须要理解高阶函数，理解中间件的使用方式，不然你不会知道为何这样写是对的：

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

为何不抹掉理解成本，直接容许 async 类型的 action 呢？

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

笔者注：咱们发现 rematch 的方式，dispatch 是 import 进来的（全局变量），而 redux 的 dispatch 是注入进来的，乍一看彷佛 redux 更合理，但其实我更推崇 rematch 的方案。通过长期实践，组件最好不要使用数据流，项目的数据流只用一个实例彻底够用了，全局 dispatch 的设计其实更合理，而注入 dispatch 的设计看似追求技术极致，但忽略了业务使用场景，致使多此一举，增长了没必要要的麻烦。

将 action + reducer 改成两种 action

redux 抽象的 action 与 reducer 的指责很清晰，action 负责改 store 之外全部事，而 reducer 负责改 store，偶尔用来作数据处理。这种概念其实比较模糊，由于每每不清楚数据处理放在 action 仍是 reducer 里，同时过于简单的 reducer 又要写 action 与之匹配，感受过于形式化，并且繁琐。

从新考虑这个问题，咱们只有两类 action：reducer action 与 effect action。

• reducer action：改变 store。
• effect action：处理异步场景，能调用其余 action，不能修改 store。

同步的场景，一个 reducer 函数就能处理，只有异步场景须要 effect action 处理掉异步部分，同步部分依然交给 reducer 函数，这两种 action 职责更清晰。

再也不显示申明 action type

不要在用一个文件存储 Action 类型了，const ACTION_ONE = 'ACTION_ONE' 其实重复写了一遍字符串，直接用对象的 key 表示 action 的值，再加上 store 的 name 为前缀保证惟一性便可。

同时 redux 建议使用 payload key 来传值，那为何不强制使用 payload 做为入参，而要经过 action.payload 取值呢？直接使用 payload 不但视觉上减小代码数量，容易理解，同时也强制约束了代码风格，让建议真正落地。

Reducer 直接做为 ActionCreator

redux 调用 action 比较繁琐，使用 dispatch 或者将 reducer 通过 ActionCreator 函数包装。为何不直接给 reducer 自动包装 ActionCreator 呢？减小样板代码，让每一行代码都有业务含义。

最后做者给出了一个 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);

3 精读

我以为本文基本上把 redux 存在的工程问题分析透彻了，同时还给出了一套很是好的实现。

细节的极致优化

首先是直接使用 payload 而不是整个 action 做为入参，增强了约束同时简化代码复杂度:

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

其次使用 async 在 effects 函数中，使用 this.increment 函数调用方式，取代 put({type: "increment"})（dva），在 typescript 中拥有了类型支持，不但能够用自动跳转代替字符串搜索，还能校验参数类型，在 redux 框架中很是可贵。

最后在 dispatch 函数，也提供了两种调用方式：

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

若是为了更好的类型支持，或者屏蔽 payload 概念，可使用第二种方案，再一次简化 redux 概念。

内置了比较多的插件

rematch 将经常使用的 reselect、persist、immer 等都集成为了插件，相对比较强化插件生态的概念。数据流对数据缓存，性能优化，开发体验优化都有进一步施展的空间，拥抱插件生态是一个良好的发展方向。

好比 rematch-immer 插件，能够用 mutable 的方式修改 store：

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

可是当 state 为非对象时，immer 将不起做用，因此最好能养成 return state 的习惯。

最后说一点瑕疵的地方，reducers 申明与调用参数不一致。

Reducers 申明与调用参数不一致

好比下面的 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);
    }
  }
};

定义时 increment 是两个参数，而 incrementAsync 调用它时，只有一个参数，这样可能形成一些误导，笔者建议保持参数对应关系，将 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);
    }
  }
};

固然 rematch 的方式保持了函数的无副做性质，能够看出是作了一些取舍。

4 总结

重复一下做者提出工具质量的公式：

工具质量 = 工具节省的时间/使用工具消耗的时间

若是一个工具能节省开发时间，但自己带来了很大使用成本，在想清楚如何减小使用成本以前，不要急着用在项目中，这是我获得的最大启发。

最后感谢 rematch 做者精益求精的精神，给 redux 带来进一步的极致优化。

5 更多讨论

讨论地址是： 精读《从新思考 Redux》 · Issue #83 · dt-fe/weekly

若是你想参与讨论，请点击这里，每周都有新的主题，周末或周一发布。