React 的应用场景
- 网页应用，Facebok，Instagram，Netflix 网页版
- 移动原生应用：Instagram，Discord，Oculus
- 桌面应用：结合 Electron
- 3D：react-three-fiber
React 的设计思路
UI 编程的痛点
- 状态更新，UI 不会自动更新，需要手动调用 dom
- 缺少代码层面的封装与隔离，没有组件化
- UI 之间存在数据依赖关系，需要手动维护；如果数据依赖关系链太长，会出现 callback hell
转换式系统 & 响应式系统
转换式系统：给定输入，求解输出，如编译器，计算器
响应式系统：监听事件，由消息驱动
前端代码并不需要大量的计算，更多的是需要去处理一些事件（比如用户的点击）；另外当事件发生时，我们需要进行一些响应（比如改变界面）。这两个特点决定了转换式系统对于前端写起来是很难受的，我们需要一种新的方式。
依据上面的分析，我们对于 React 设计的期望也很容易得出：
- 状态更新，UI 自动更新
- 前端代码组件化，可以复用，可以封装
- 状态之间
组件化
- 组件是组件的组合 / 原子组件
- 组件内拥有状态，且外部不可见
- 父组件可以把状态传递给子组件
状态归属
状态提升：当多个组件需要共享一个状态的时候，我们需要不断地提升状态，所以我们需要状态管理库。
注意 React 不是双向数据流，是单向的。子组件只是执行了父组件传递过来的函数，而没有把任何的状态传递回去给父组件。（函数在 Js 中是一等公民，所以可以作为一个变量传递）
组件设计
- 组件声明了状态以及 UI 的映射
- 组件有 state（内部状态）和 props（外部状态）两种状态
- 组件可以由其它组件拼装而成
状态管理库
使用状态管理库的弊端：组件的复用性降低了，一般使用于业务代码
常用的状态管理库有：
- redux
- mobx
- xstate
- recoil
- reduck（来源于 modern.js）
什么东西应该放到状态管理库？
如果你觉得某个东西整个 APP 有多处可能用到的，就放进去，比如说用户头像，这样也可以减少我们发送的请求数。
React 组件什么时候被渲染？
- 首次渲染
- props 变化
- state 变化
- context 变化
应用级框架科普
- Next.js
- Modern.js
- Blitz