这是我参与「第四届青训营 」笔记创作活动的第10天
React的设计思路 —— 状态归属问题
React 是单向数据流 —— 永远只能由父组件向子组件传递消息，但是并不代表子组件不能改变父组件的状态，因为父组件可以把一个函数传给子组件，子组件可以执行这个函数，从而实现我们的目的。
观察其他Hooks可能会发现，其他Hooks是基于useState和useEffect的封装，要注意不要在循环、条件或嵌套函数中调用Hook.
既然几乎所有的前端框架都是声明式编程，那么为什么不把声明式的能力植入我们的浏览器，也就是让我们的浏览器支持声明式语法，这样我们就不需要去import React 或者 Vue包？ 这是因为，浏览器作为一个应用平台，他自己不能够给我们提供更高层的东西，因为有的人可能喜欢指令式编程，有的人喜欢声明式编程，而不能说，只给你声明式的语法，浏览器只能去给你最基础的平台，去支持你实现各种上层封装。
当状态变化相关联的两个节点位置距离比较远时，很容易发生，状态堆积，比如堆积到根节点，这是一个不好的现象，那么我们怎样解决呢，这时就需要我们React状态管理库了，将状态抽离到UI外部进行统一管理，从而实现状态共享，从而避免了我们从根节点一直往下传传传的过程。 但是既然可以这样处理，那么为什么我们还要把状态放在UI内部呢？这是因为这种方案也是有坏处的——会降低组件的复用性，相当于组件和外部的一个状态Store强耦了，相当于这个组件偏业务属性了，而我们所期望的 React 组件库，应当是一个个抽象的非常好的，复用性很强的，而不能够去依赖一个外部的状态库，这往往出现在业务代码中。
React 状态管理库
- 思想：将状态抽离到组件外部统一管理。（推荐的四个，其实选哪一个都行，基本思想都是一样的）
- 状态机：当前状态，收到外部事件，迁移到下一个状态。
那么我们什么时候去应用这个状态管理库呢？
可以根据这样一个准则——判断这个状态是被整个APP所拥有的（比如用户头像）还是被某个组件所拥有的，根据自己的理解来权衡是否需要状态管理库。
6.应用级框架科普
React 其实本质上是一个JS库，它并没有给我们提供很多工程能力，比如说路由，构建配置，页面配置，服务端渲染等，都没有给我们提供，下图老师给我们安利了三个前端框架。
