很喜欢 Jotai。优点:
- API 简单
- 性能卓越。
缺点：
- 状态(atom)多了后，散落在不同文件里，不好管理。
- 必须在 React 组件或 hooks 里用。
各状态管理库对比
| 框架 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| hooks context | 基于 React Hook，开发者可实现内/外部存储 | 1. 使用简单 2. 不需要引用第三方库，体积最小 3. 支持存储全局状态，但在复杂应用中不推荐 4. 不依赖 React 上下文，可在组件外调用（外部存储的条件下） | 1. Context value 发生变化时，所有用到这个 Context 的组件都会被重新渲染，基于 Context 维护的模块越多，影响范围越大。 2. 依赖 Context Provider 包裹应用，修改 store 无法在应用最顶层 (App.tsx 层级) 触发渲染 3. 受 UI 框架约束 (React) 4. 依赖 Hooks 调用 |
| react-redux | Flux 思想，发布订阅模式，遵从函数式编程，外部存储 | 1. 不依赖 React 上下文，可在组件外调用 2. 支持存储全局状态 3. Redux 本身是一种通用的状态解决方案 | 1. 心智模型需要时间理解，特别是当你不熟悉函数式编程时 2. 依赖 Context Provider 包裹应用，修改 store 无法在应用最顶层 (App.tsx 层级) 触发渲染 3. 受 UI 框架约束 (React) |
| mobx | 观察者模式 + 数据劫持，外部存储 | 1. 使用简单，上手门槛低 2. 不依赖 React 上下文，可在组件外调用 3. 支持存储全局状态 4. 通用的状态解决方案 | 1. 可变状态模型，某些情况下可能影响调试 2. 体积相对较大，3.99M |
| zustand | Flux 思想，观察者模式，外部存储 | 1. 轻量，使用简单，上手门槛低 2. 不依赖 React 上下文，可在组件外调用 3. 支持存储全局状态 4. 通用的状态解决方案 | 1. 框架本身不支持 computed 属性，但可基于 middleware 机制通过少量代码间接实现 computed，或基于第三方库 zustand-computed 实现 |
| jotai | 基于 React Hook，内部存储 | 1. 使用简单 2. 组件颗粒度较细的情况下，Jotai 性能更好 3. 支持存储全局状态 | 1. 依赖 React 上下文，无法在组件外调用，相对而言，Zustand 在 React 环境外及全局可以更好地工作 2. 受 UI 框架约束 (React) |
| recoil | 进阶版 Jotai，基于 React Hook + Provider Context，内部存储 | 相对于 Jotai 而言，会更重一些，但思想基本不变，拥有一些 Jotai 未支持的特性及 API，如： 1. 监听 store 变化 2. 针对 atom 的操作拥有更多的 API，编程上拥有更多的可能性，更加有趣 | 拥有 Jotai 所有的缺点，且相对于 Jotai 而言: 1. 使用 Recoil 需要 <RecoilRoot> 包裹应用程序 2. 编写 selector 会更复杂 |
| valtio | 基于数据劫持，外部存储 | 1. 使用简单，类 MobX（类 Vue）的编程体验 2. 支持存储全局状态 3. 不依赖 React 上下文，可在组件外调用 4. 通用的状态解决方案 | 1. 可变状态模型，某些情况下可能影响调试 2. 目前未发现其它特别大的缺点，个人猜测 Star 相对 Zustand 较少，可能是因为 Valtio 的数据双向绑定思想与 React 存在冲突 |