什么是状态管理?
状态
状态是表示组件当前状况的 JS 对象。在 React 中,可以使用 useState 或者 this.state 维护组件内部状态,通过 props 传递给子组件使用。
为了避免状态传递过程中出现混乱,React 引入了“单向数据流”的理念。主要思想是组件不会改变接收的数据,只会监听数据的变化,当数据发生变化时他们会使用接收到的新值,而不是修改已有的值。当组件的更新机制触发后,他们只是使用新值进行重新渲染。
父子组件通信可以直接使用 props 和回调方式;深层次、远距离组件则要通过“状态提升”和 props 层层传递。
常见模式
React 状态管理的常见模式有:
- 状态提升:兄弟组件间是没法直接共享状态的,可以通过将状态提升到最近的祖先组件中,所有兄弟组件就可以通过 props 一级级传递获取状态;
- 状态组合:某些状态可能只在应用程序的特定子树中需要。最好将状态存储在尽可能接近实际需要的位置,这有助于优化渲染行为;
- 属性下钻:将父组件的状态以属性的形式一级级显示传递给嵌套子组件;
- Provider:React Context 通过 Provider 包裹组件,被包裹的所有嵌套子组件都可以不用通过属性下钻而是通过 context 直接获取状态。
层层传递的 value onChange 会对一个优质代码库带来的毁灭性影响,粗暴地把数据塞在 redux 中也并不能让一个应用得到很好的拓展性和可维护性。
要解决的问题
状态管理库要解决的问题:
- 从组件树的「任何地方」读取存储的状态
- 写入存储状态的能力
- 提供「优化渲染」的机制
- 提供「优化内存使用」的机制
- 与「并发模式的兼容性」
- 数据的「持久化」
- 「上下文丢失」问题
- 「props失效」问题
- 「孤儿」问题
心智模型
状态更新有两种心智模型:
- 不可变状态模型
- 可变状态模型
- 主要好处是可以使用原生 JS 方法;
- 基于 Proxy 的状态管理的一个缺点是状态不可预测,难以 debug。
因为 React 没有官方的状态管理方案,React 生态中状态管理库,百花齐放,演进出很多设计思想和心智模式。如何选择状态管理库就变得十分令人抓狂。
React Context
在多级嵌套组件场景下,使用“属性下钻”方式进行组件通信是一件成本极高的事情。为了解决这个问题,React 官方提供 Context 用于避免一级级属性传递。
Context 的问题
Context存在的问题也是老生常谈。在 react 里,context 是个反模式的东西,不同于 redux 等的细粒度响应式更新,context的值一旦变化,所有依赖该context的组件全部都会 force update,因为 context API 并不能细粒度地分析某个组件依赖了context 里的哪个属性,并且它可以穿透 React.memo 和 shouldComponentUpdate 的对比,把所有涉事组件强制刷新。
React官方文档在 When to Use Context一节中写道:
Context 设计目的是为了共享那些对于一个组件树而言是“全局”的数据,例如当前认证的用户、主题或首选语言。
综上,在系统中跟业务相关、会频繁变动的数据在共享时,应谨慎使用 context。
如果决定使用context,可以在一些场景中,将多个子组件依赖的不同context属性提升到一个父组件中,由父组件订阅context并以prop的方式下发,这样可以使用子组件的memo、shouldComponentUpdate生效。
此外,官方文档还提到了另外一个坑,使用的时候也应该注意。
优点
- 作为React内置的hook,不需要引入第三方库;
- 书写还算方便。
缺点
- Context 只能存储单一值,当数据量大起来时,你可能需要使用createContext创建大量context;
- 直接使用的话,会有一定的性能问题:每一次对state的某个值变更,都会导致其他使用该state的组件re-render,即使没有使用该值。 你可以通过useMemo来解决这个问题,但是就需要一定的成本来定制一个通用的解决方案;
- 无法处理异步请求。对于异步的逻辑,Context API并没有提供任何API,需要自己做封装;
- 无法处理数据间的联动。Context API并没有提供API来生成派生状态,同样也需要自行去封装一些方法来实现。
React 外部状态管理库
概览
React 的外部状态管理库一直以来是 React 生态中非常内卷的一个领域。目前比较常见的状态管理库有 Redux(包括基于 Redux 的 Dva、Icestore)、Mobx、Zustand、Recoil、Jotai、Valtio、Hox 等。
从 npm trends 看各个状态管理库近一年的下载量趋势:
我们可以看到 Redux 作为 React 状态管理的老大哥,下载量上依然遥遥领先其他库。Mobx 作为往年热度仅次于 Redux 的状态管理库,位置正逐步有被 zustand 超越的趋势。recoil/jotai/valtio 作为这两年热门的新兴库热度也在逐步上升。hox 则处于不温不火的尴尬地位。
将以上状态管理库按心智模型、诞生时间、star 数,绘制气泡图。以 React v16.8 版本为分水岭,状态管理库可分为 Class 时代和 Hooks 时代。Class 时代中 Redux 和 Mobx 都是非常优秀的状态库。随着 Hooks 时代的到来,状态管理的心智模型也逐步发生着演变。整体呈现从中心化到去中心化,从单一状态到原子状态,从 Provider 到拥抱 Hooks 等演变趋势。
下面,我们对上述状态管理库进行逐一对比介绍。
Class 时代
Redux
Redux 的灵感来源于 Flux 架构和函数式编程原理,状态更新可预测、可跟踪,提倡使用「单一存储」。这通常会「导致将所有的东西存储在一个大的单体存储中」。将UI和远程实体状态之间的所有东西都放在一个地方管理,这变得非常难以管理。对性能造成了不小的压力。
单向数据流
他的工作流程大致如下:
- 用户在view层触发某个事件,通过dispatch发送了action和payload
- action和payload被传入reducer函数,返回一个新的state
- store拿到reducer返回的state并做更新,同时通知view层进行re-render
由此可看出 Redux 遵循“单向数据流”和“不可变状态模型”的设计思想。这使得 Redux 的状态变化是可预测、可调式的。
三大原则
此外,Redux 还遵循三大原则:
- 单一数据源
整个应用的 全局 state被储存在一棵 object tree 中,并且这个 object tree 只存在于唯一一个 store中。
- state 是只读的
唯一改变 state 的方法就是触发 action,action 是一个用于描述已发生事件的普通对象。
- 纯函数修改
通过 reducer 修改状态,reducer 是纯函数,它接收之前的 state 和 action,并返回新的 state。记住,一定要返回一个新的对象,而不是修改之前的 state。
如何处理异步
redux没有规定如何处理异步数据流,最原始的方式就是使用Action Creators,也就是在制造action之前进行各种的异步操作,你可以把要复用的操作抽离出来。
当然这样并不优雅,在实际项目中我们通常使用类似redux-thunk、redux-saga这些中间件来支持处理异步。
如何处理数据间联动
react-redux的useSelector获取状态后,你可以编写一些逻辑来处理派生状态。如果派生状态需要复用,记得给抽离出来。
优点
- 繁荣的社区,像不支持异步这种问题是由成熟的中间件可以解决的,你遇到的问题多多少少可以在社区找到答案;
- 可扩展性高,中间件模式让你可以随心所欲的武装你的dispatch;
- 单一数据源且是树形结构,这让redux支持回溯,在调试上也更方便;
- 有成熟的开发调试工具 redux devtools。
缺点
- 陡峭的学习曲线。将副作用扔给中间件来处理,导致社区一堆中间件,学习成本陡然增加。比如处理异步请求的 Redux-saga、计算衍生状态的 reselect;
- 大量的模版代码。使用 redux,开发者要编写大量和业务逻辑无关的模板代码,这给开发和后期维护都带来了额外的成本;
- 大状态量情况下,性能较差。state 更新会影响所有组件。每个 action 都会调用所有 reducer;
- reducer 要返回新的对象,如果更新的值层级较深,更新成本也很高;
- 更多的内存占用,由于采用单一数据源,所有状态存储在一个 state 中,当某些状态不再需要使用时,也不会被垃圾回收释放内存;
当然,redux 也在致力于解决上述缺点。比如,redux toolkit就旨在让开发者使用标准方式编写 redux 逻辑。主要解决 redux 的 3 个问题:
- 配置 redux store 过于麻烦;
- 必须手动额外添加很多包才能正常使用 redux;
- redux 需要太多模板代码。
不过,即使有 redux toolkit 的加持,redux 的学习成本依旧不低。
Dva
dva 首先是一个基于 redux和 redux-saga的数据流方案,然后为了简化开发体验,dva 还额外内置了 react-router和 fetch,所以也可以理解为一个轻量级的应用框架。
Dva 的特点:
- 易学易用,仅有 6 个 api,对 redux 用户尤其友好,配合 umi 使用后更是降低为 0 API
- elm 概念,通过 reducers, effects 和 subscriptions 组织 model
- 插件机制,比如 dva-loading可以自动处理 loading 状态,不用一遍遍地写 showLoading 和 hideLoading
- 支持 HMR,基于 babel-plugin-dva-hmr实现 components、routes 和 models 的 HMR
Dva 大幅降低了 Redux 的上手成本,过去也在社区拥有了拥趸,github star 数 16.1k。不过,从 2019.11 开始就没有新的版本发布,看起来已经处于不维护状态。
icestore
icestore 是 IceJs内置状态管理库。icestore 是面向 React 应用的、简单友好的状态管理方案。
它包含以下核心特征:
- 简单、熟悉的 API:不需要额外的学习成本,只需要了解 React Hooks,对 Redux 用户友好。
- 集成异步处理:记录异步操作时的执行状态,简化视图中对于等待或错误的处理逻辑。
- 支持组件 Class 写法:友好的兼容策略可以让老项目享受轻量状态管理的乐趣。
- 良好的 TypeScript 支持:提供完整的 TypeScript 类型定义,在 VS Code 中能获得完整的类型检查和推断。
icestore 的灵感来自于 rematch和 constate。整体实现和 rematch 基本一致。rematch 是一个没有模板代码的 redux 最佳实践。icestore 整体配置简单,解决了 redux 学习成本高、大量模板代码等问题,同时又很好的支持了异步处理、TypeScript 和 SSR。
IceJS 自己给出的能力对照表:
- O: 支持
- X: 不支持
- +: 需要额外地进行能力扩展
功能/库 | redux | constate | zustand | react-tracked | icestore |
---|---|---|---|---|---|
框架 | Any | React | React | React | React |
简单性 | ★★ | ★★★★ | ★★★ | ★★★ | ★★★★ |
更少的模板代码 | ★ | ★★ | ★★★ | ★★★ | ★★★★ |
可配置性 | ★★ | ★★★ | ★★★ | ★★★ | ★★★★★ |
共享状态 | O | O | O | O | O |
复用状态 | O | O | O | O | O |
状态联动 | + | + | + | + | O |
Class 组件支持 | O | + | + | + | O |
Function 组件支持 | O | O | O | O | O |
异步更新的状态 | + | X | X | X | O |
SSR | O | O | X | O | O |
持久化 | + | X | X | X | + |
懒加载模型 | + | + | + | + | O |
中心化 | + | X | X | X | O |
中间件或插件机制 | O | X | O | X | O |
开发者工具 | O | X | O | X | O |
Mobx
设计思想
MobX 的主要思想是用「函数响应式编程」和「可变状态模型」使得状态管理变得简单和可扩展。
MobX背后的哲学很简单:
任何源自应用状态的东西都应该自动地获得。其中包括UI、数据序列化、服务器通讯,等等。
React 和 MobX 是一对强力组合。React 通过提供机制把应用状态转换为可渲染组件树并对其进行渲染。而MobX提供机制来存储和更新应用状态供 React 使用。
对于应用开发中的常见问题,React 和 MobX 都提供了最优和独特的解决方案。React 提供了优化UI渲染的机制, 这种机制就是通过使用虚拟DOM来减少昂贵的DOM变化的数量。MobX 提供了优化应用状态与 React 组件同步的机制,这种机制就是使用响应式虚拟依赖状态图表,它只有在真正需要的时候才更新并且永远保持是最新的。
心智模型
Mobx的心智模型和react很像,它区分了应用程序的三个概念:
- State(状态)
- Actions(动作)
- Derivations(派生)
首先创建可观察的状态(Observable State),通过Action更新State,然后自动更新所有的派生(Derivations)。派生包括Computed value(类似useMemo或useSelector)、副作用函数(类似useEffect)和UI(render)。
Mobx虽然心智模型像 react,但是实现却是完完全全的 vue:mutable + proxy(为了兼容性,proxy实际上使用Object.defineProperty实现)。
使用反react的数据流模式,注定会有成本:
- Mobx的响应式脱离了react自身的生命周期,就不得不显式声明其派生的作用时机和范围。比如副作用触发需要在useEffect里再跑一个autorun/reaction,要给DOM render包一层useObserver/Observer,都加大了开发成本。
- Mobx会在组件挂载时收集依赖,和state建立联系,这个方式在即将到来的react 18的并发模式(Concurrent Mode)中,可能无法平滑地迁移。为此,react专门开发了create-subscription方法用于在组件中订阅外部源,但是实际的应用效果还未可知。
尤大本人也盖过章:React + MobX 本质上就是一个更繁琐的Vue。
Mobx vs Redux
Mobx和Redux的对比,实际上可以归结为 面向对象 vs 函数式和 Mutable vs Immutable。
- 相比于redux的广播遍历dispatch,然后遍历判断引用来决定组件是否更新,mobx基于proxy可以精确收集依赖、局部更新组件(类似vue),理论上会有更好的性能,但redux认为这可能不是一个问题(Won't calling “all my reducers” for each action be slow?)
- Mobx因为数据只有一份引用,没有回溯能力,不像redux每次更新都相当于打了一个快照,调试时搭配redux-logger这样的中间件,可以很直观地看到数据流变化历史。
- Mobx的学习成本更低,没有全家桶。
- Mobx在更新state中深层嵌套属性时更方便,直接赋值就好了,redux则需要更新所有途经层级的引用(当然搭配immer也不麻烦)。
优点
- 简单易用,没有模板代码;
- 精准更新,性能更好;
缺点
- 难以调试。由于采用可变状态模型,状态不可预测和追溯,难以 debug;
- 太过灵活,更容易导致 bug;
- 响应式是基于 Proxy 实现的,希望传递的是一个数组,拿到的却是一个 Proxy。排查问题时有点痛苦。
Hooks 时代
Hooks 是 React 16.8 新增的特性,使得我们可以在函数组件中使用 state 以及其他 React 特性。
Hooks 的引入主要是为了解决 React Class 组件的以下问题:
- 在组件之间复用状态逻辑很难
Class 组件会将视图和状态逻辑糅杂在一起,如果想复用组件中的状态逻辑,需要使用 render props 和高阶组件,但是这类方案需要重新组织组件结构,会形成组件的嵌套地狱,代码逻辑也会变得难以理解。
- 复杂组件的理解成本很高
Class 组件的状态逻辑会充斥在各个生命周期中,完全不相关的代码出现在同一个生命周期函数中,逻辑难以理解,容易引发 bug,且在多数情况下,很难将组件拆分成更小的粒度。
Hooks 是一种开发理念和组织理念的革新,有 3 个特性:
- primitive。元数据化,将混沌的 state 打散为一个个元数据;
- decentralization。去中心化,Class 时代的理念是“顶层下发”,Hooks 带来了强烈的“组件自治”理念;
- algebraic effects。代数效应,剥离组件中的副作用,让开发者更专注业务逻辑。
代数效应是函数式编程中的一个概念,用于将副作用从函数调用中分离。
自下而上模式的崛起
我们可以看到以前的状态管理解决方案,如Redux,设计理念是状态 「自上而下」流动。它「倾向于在组件树的顶端吸走所有的状态」。状态被维护在组件树的高处,下面的组件通过选择器拉取他们需要的状态。
在新的组件构建理念中,一种「自下而上」的观点对构建具有组合模式的应用具有很好的指导作用。
而hook就是这种理念的践行者,即把可组合的部件放在一起形成一个更大的整体。
通过 hook,我们可以从具有巨大全局存储的「单体状态管理」转变为向自下而上的 「微状态管理」,通过hook消费更小的状态片。
像接下来要介绍的 Recoil 和 Jotai 这样的流行库以其 「原子状态」的概念体现了这种自下而上的理念。「原子是一个最小但完整的状态单位」。它们是小块的状态,可以连接在一起形成新的衍生状态。最终形成了一个应用状态图。
这个模型允许你自下而上地建立起「状态图」。并通过仅使图中已更新的原子失效来优化渲染。
这与拥有一个大的单体状态球形成鲜明对比,你可以「订阅并试图避免不必要的渲染」。
接下来我们要介绍 5 个 Hooks 时代的状态库,分别是 recoil、zustand、jotai、valtio、hox。比较有趣的是其中 3 个都是 Daishi Kato开发的,采用了不同的设计思想,但是都在短期内取得不错的社区热度,这 3 个库分别是 zustand、jotai、valtio,这三个词其实是“状态”在 3 种语言中的不同发音。
zustand