React状态管理 | 青训营笔记

前置疑问

1.因为全局对象中可能会有污染，重复声明

2.直接取值和赋值的时候，不太直观

3.无法控制渲染力度

4.无法进行redux的时间旅行

1.react的新特性，都不会考虑类组件，都直接用hooks

2.类组件很复杂

因为react遵循的是单项数据流的原则，属性通过Props自下而上的传递。当页面的比较简单，组件之间的层级关系比较浅时，这种自上而下的单向数据流的方式是不会有问题的。如果页面一复杂，组件的嵌套层级一深，这种单向数据流的传递方式，将会让你陷到嵌套地狱。

状态管理本身，解决的就是这种嵌套地狱的问题，解决的是跨层级组件之间的数据通信和状态共享

状态管理工具的本质：管理共享内存中的状态

1.共享内存

2.管理状态

3.页面通信

4.组件通信

5.刷新失效

详细定义：单页应用的各个组件本身是共享内存的，如果将状态保存在内存中，就可以读写统一内存中的变量，从而达到状态共享的目的。

context的问题：渲染力度有不可控制，有一些没有用context的值的子组件都会被重新渲染（解决方法用）；需要用provider包裹它，会变成一个金字塔结构

view react的ui层

dispatch层是来接收action（触发更新动作）和执行状态的更新逻辑都耦合在一起了

1.发出一个对象类的事件

2.再注册这个事件

redux这里解耦了action和dispatch，可以直接通过dispatch发出一个action，不需要注册。解耦了store和reducer。

有多个context的话就会变成一个金字塔结构，会诞生一些不必要的渲染

不同的子状态变成一个新状态

而context只能从根节点开始渲染

两个api，一个是create定义，一个是use使用

创建store的时候也可以创造方法

有个构造函数，简易的redux

listen 监听数组，subscrbie监听函数，dispatch发出一个状态改变函数，getstate返回当前状态

有的时候直接用zustand就可以了