课程介绍
本节课将聚焦于 React 相关的状态管理库和目前常见的应用级框架科普，前者主要是讲解其中的底层逻辑，后者通过对框架的科普，帮助大家应对不同开发场景。
课程重点
- React 状态管理库 - 核心思想
- React 状态管理库 - 推荐
- React 状态管理库 - 状态机
- React 状态管理库 - Modern.js/Reduck
- 应用级框架科普
引出主题
如果我们把一些组件的状态上升到根节点，当两个位置比较远的组件想共享状态的时候，如果非要把状态放到组件内部，它就会让这个状态充斥在一个很高的位置上，所有的状态都会堆积到一个根节点上。 有没有其他的方法可以解决这个问题？
React 状态管理库可以解决。
React 状态管理库的核心思想
状态应该放到组件的内部？ 没有人说这一定是对的，我为什么状态不能把放在组件的外部？
假设我外部存在一个特别大的状态仓库，这个状态仓库里面包含各种各样的状态，所有的 UI 组件都直接和这个大的数据 store 去做数据交互。 如下图右侧。这样我不就实现了状态的共享了吗？ 这样的思路可以解决我们状态共享的问题。
但是还有一个新的问题，既然这个可以，那为什么我们还要把状态放在组件的内部？ 这种方案有一定的缺陷。 这种方案会降低组件的复用性，就相当于你这个组件和外部的某一个数据 Store 强耦合。 如果你现在要开发一个组件库，你能不能让一个组件库内部去依赖一个外部的数据Store？ 这完全不可能，理论上来说一个组件库的组件应该是抽象很好，复用性很强的。
因此大家可以发现，组件出现依赖于外部的数据 Store 基本出现在实际的业务代码中，就是你的这个 APP中。 但是library 不会这样做。
本身从语义上说，如果一个状态完全地被一个组件所拥有，那么这个状态不应该被其他组件所看到。也就是说，我们最好只在这个 store 里放那些需要不同的组件，或者距离非常远的组件，需要共享的状态。放到这个 store 里。
是不是有点难理解？ React 状态管理库官方有一个这样的解释：
我们可以把这个东西看作，这整个所有的节点，是一个大的 UI 组件，我把这个所有的组件拼在一起，看成一个特别大的组件。这个 store 是这个特别大的组件的一个 state。
React 状态管理库推荐
- redux
- xstate 基于状态机思想去做的，整个状态管理库可以理解为一个大的状态机。
- mobx
- recoil
不管是哪个，核心思想是不变的：讲状态抽离到 UI 外部进行统一管理。
状态机
什么是状态机？ 上图的红绿灯就是一个状态机。 例如红灯，绿灯，黄灯的转换。
到底哪些东西适合放在状态管理库？
你觉得这个状态是被整个APP所拥有的，还是说这个状态被某一个组件所拥有的。
Modern.js/Reduck
Modern.js 基于 React 的全栈开发框架。它的状态管理工具 Reduck
应用级别框架科普
React 本身是JavaScript library 本身没有给我们提供足够多的工程的能力，比方说路由、构建配置、页面路由、服务端渲染等都没有配置。
- NEXT.js
- Moder.js
- Blitz
大家加油呀，好好学习！
