react全局状态管理_Hooks 时代的 React 状态管理方案

本文是对回答《React Hooks 自去年 10 月发布以来，社区和国内外团队的接受程度如何？》的延伸。

在 React 团队发布 Hooks 之前，React 状态管理方案的主流选择，基本上就是 Redux 和 Mobx。不过社区中一直都有“你不需要 Redux”的呼声，各种号称要取代 Redux 状态管理方案也都层出不穷。随着 Hooks 的发布，React 社区又掀起了一波基于 Hooks 的造轮子大潮。目前看来，基于 Hooks 的状态管理方案大致可以分为两大类。

纯 Hooks 实现

以 constate 和 unstate-next 为代表的纯 Hooks 方案。其核心思想还是“你不需要状态管理库”，利用 Hooks 你就可以很好的管理状态了。所以这类方案的实现也非常简单，两个库的代码都在 50 行以内。他们更多的是提供了一种定义 Hooks 并且将状态共享的模式。

这类方案的优点就是简单，没有花里胡哨的概念，你写的就是 React Hooks，社区大量的 Hooks 库也可以直接拿来用。

缺点就是你要把 Hooks 的状态变成全局的话你的应用需要套一大堆 Provider。而且因为其简单的实现，这类方案也不会对 consumer 组件做优化，要优化就需要自己用 React.memo 。

先定义 model，再以 Hooks 的方式消费

使用这类方案的库：

• Overmind
• Ayanami
• Overstated

这类方案先以配置或者 Class 的方式定义一个 model（每个库都有不同的叫法，我们暂且全称之为 model），然后再以 Hooks 的方式去消费。

这类方案不同于纯粹的 Hooks 方案，一般会额外提供诸如副作用处理、中间件、devtools（或者兼容 Redux devtools）等功能。缺点就是会有一点学习曲线，也无法在 model 中复用社区里的大量 Hooks。

再说说 Dva（Redux）

Dva 或这说 Redux 最被人诟病的就是样板代码太多。光发一个请求可能就需要 3 个 action，1 个 effect，2 个 reducer，最后还要 connect。

另外在 TypeScript 大行其道的今天，Redux 对 TypeScript 的支持也是非常的弱，其字符串方式的 action type 天生就对 TypeScript 不友好。而以上提到的方案均对 TypeScript 有非常好的支持。

Dva 选择的 redux-saga 也有点屠龙刀的感觉，redux-saga 本身是很强大的，第一看它的文档的时候，我也是觉得大开眼界。但是实际项目中其实很少有龙需要屠（也可能是我接触的项目确实不够复杂），redux-saga 50 个左右的 API，我们常用的估计也就 5 个，大部分人可能也就知道这几个 API。

所以， Dva 下个版本的要解决上面的问题，要拥抱 Hooks，应该是朝上文第二个方案的方向走。model 的方案跟 Dva 目前的模式类似，也对老项目的升级和兼容会比较友好。