一、什么是状态管理
状态管理工具的本质:管理共享内存中的状态。
1.共享内存；2.管理状态；3.页面通信4.组件通信5.刷新失效?
详细定义:单页应用的各个组件本身是共享内存的，如果将状态保存在内存中，就可以读写统一内存中的变量，从而达到状态共享的目的。
二、为什么React有这么多状态管理工具?
Vue: Vuex(Pinia)
Angular： Service和Rxjs
React： Flux、 Redux、 Mobx、Rxjs、 Recoil、Jotai、Zustand
跟不同前端框架的定义有关，Vue和Angular双向数据绑定，计算属性等，数据是响应式的，控制视图刷新，拥有计算属性等，这些使得Vue和Angular需要状态管理的场景减少，此外其本身就包含了完整的状态管理工具，比如Vue的Vuex和Pinia, Angular的Service(RXjs)等，从官方定调。而React不一样，React是一个纯UI层的前端框架，Uls fn(state), React将状态的变动完全交给开发者。
三、 React状态管理简介
React状态管理工具可以分为以下几类:
React自带:Local State(props)和Context
单向数据流:Flux、 Redux(Redux-toolkit)
双向数据绑定:Mobx
原子型状态管理: Recoll、Jotal
异步操作密集型: Rxjs
每一种状态管理工具都有其不同的适用性，不同场景下需要合理的选择状态管理工具。
四、状态管理简介
React中的Context解决了react中，props或者state进行多级数据传递，则数据需要自顶下流经过每一级组件，无法跨级的问题。但是Context在页面间共享数据的时候同样有很多问题:
1.Context相当于全局变量，难以追溯数据的变更情况
2.使用Context的组件内部耦合度太高，不利于组件的复用和单元测试
3.会产生不必要的更新(比如会穿透memo和dependicies等)
4.Context 只能存储单一值，无法存储多个各自拥有消费者的值的集合。
5.粒度也不太好控制，不能细粒度的区分组件依赖了哪一个Context
6.多个Context会存在层层嵌套的问题
Flux利用数据的单向流动的形式对公共状态进行管理。
View:视图层
Action:视图发出的消息
Dispatcher: 派发者，用来接收Action,执行回调函数
Store:数据层，存放状态，一旦发生改动，就会更新数据以及emit相关事件等
五、 Redux在项目中的实践
1.如何使用Redux
redux的本质:redux做为一款状态管理工具，主要是为了解决组件间通信的问题。
既然是组件间的通信问题，那么显然将所有页面的状态都放入redux中，是不合理的，复杂度也很高。
如果存在副作用函数，那么我们需要首先处理副作用函数，然后生成原始的js对象。如何处理副作用操作，在redux中选择在发出action,到reducer处理函数之间使用中间件处理副作用。
在有副作用的action和原始的action之间增加中间件处理，从图中我们也可以看出，中间件的作用就是:转换异步操作，生成原始的action,这样，reducer函数就能处理相应的action, 从而改变state,更新UI。
因为中间件，纯函数Reducer等使得Redux需要写很多样板代码，使用起来越来越复杂，早期我们使用redux-thunk,或者redux-saga等，但是复杂度还是在那里，因此在项目中不推荐使用如此复杂的Redux以及相关逻辑。
