Flux、Atomic、Proxy 不同心智模型状态管理库的比较和原理

context + useReducer

缺点

• Provider 传递的状态如果不使用 useMemo 跟 useCallback 封装，以及 Child 不使用 memo，在 Provider 的组件 re-render 时，所有使用到 context 的地方都会被重新渲染
• 如果 Provider 传递的状态越来越多时，经常会因为 Provider 的其中一状态改变导致整颗子树都 re-render
  • 要解决这个问题则是要把 Provider 的状态切分的更细，用不同的 Provider 分离状态。但如果分成多个 Provider，随着需要管理的状态越来越多，Provider 也会越来越多，介时也不好管理
• 需要解决的问题
  • props drilling 的问题
  • context 造成整颗子树渲染的问题

Flux

• 单向数据流和状态不可变性：Flux 架构强调单向数据流，这意味着应用中的数据只能按照一个方向流动。组件触发 Actions，Actions 被 Dispatcher 处理，然后更新 Store 中的状态，最后 Store 的变化反馈到视图组件
• 在 Flux 架构中，Dispatcher 是管理所有 Actions 分发的中心。每个 Action 在到达 Store 之前必须通过 Dispatcher。这种方式使状态变化更加可预测（Vuex mutation 也是参考了这种方式）
• 状态定义心智模型是先定义大的 store（即自上而下）
• 是一个外部 store，然后通过比如 hook 将外部世界连接到 React 世界

代表库

• Redux、Zustand、Vuex
  • Jotai 在日语中是“国家”的意思。 Zustand 在德语中是“国家”的意思

源码解析

Redux
Vuex

Atomic

• 在基于原子操作的状态管理方案中，状态被划分为多个独立的、不可分割的单元（原子）。每个原子代表应用状态的一个最小部分
• 状态定义心智模型是由原子组成（即自下而上），由原始原子组成并允许将它们组合在一起，组件可以订阅并更新这些原子，而不需要关心全局状态树的其他部分
• 原子不是创建多个上下文，而是共享一个大上下文
• 和 Flux 模型区别在单向数据流和状态配置方面

代表库

• jotai、Recoil、Hox、Pinia

源码解析

Hox
Pinia

Proxy

• 操作符合人类思维：通过使用 JavaScript 类似 Proxy 特性来创建可变的状态树。这允许开发者以非常直观和自然的方式操作状态，就像操作普通的 JavaScript 对象一样。状态的变化会自动触发组件的重新渲染
• 心智模型减少了状态不可变性带来的复杂性和样板代码，使状态管理更加简单直接。通过类似 Proxy 的方式实现了响应式更新，具有更细粒度的更新
• 和 Flux 模型区别在状态不可变性

代表库

• Valtio、Mobx

源码解析

待续…