引言
UI = render(data)
React 的视图会随着数据的变化而变化
“组件间通信”的背后是一套环环相扣的 React 数据流解决方案，许多人仍然会因为知识的系统性和整体性不强而吃亏
铺陈大量的前置知识
然后一步一步地去询问生命周期背后的“Why”
最终揪出 Fiber 架构这个大 boss
这些知识本身并不难，但摊子可以铺得非常大
相关的问题在面试中也始终具备较高的区分度
基于 props 的单向数据流
组件，从概念上类似于 JavaScript 函数。它接受任意的入参（即“props”）并返回用于描述页面展示内容的 React 元素。
单向数据流
当前组件的 state 以 props 的形式流动时
只能流向组件树中比自已层级更低的组件
- 父-子：传一个数据
- 子-父：传一个函数
- 兄弟：转化为父子-子父
为什么不推荐用 props 解决其他场景的需求
层层传递
- 同层传递的优化是非常简单，用已有的知识就能解决
- 问题是会浪费很多代码，而且繁琐
利用“发布-订阅”模式驱动数据流
“发布-订阅”模式，可谓是解决通信类问题的“万金油”
- socket.io 模式就是一个典型的跨商发布-订阅模式的实现
- Node.js中，许多原生模块也是以 EventEmitter 为基类实现的
- Vue.js 中作为常规操作被推而广之的“全局事件总线” EventBus
理解事件的发布-订阅机制
el.addEventListener("click", func, false)
监听事件的位置和触发事件的位置是不受限的。
设计思路
“发布-订阅”模式还是面试官的心头好，接下来我就手扰手带你来做这道题。
写出一个同时拥有 on、emit 和 off 和 EventEmitter。
这个其实就是一个观察者模式，看一下设计模式就解决了。简单的很~
如何实现发布？
相关代码略，就想像成 notification 就好了。
总结
- 使用基于 Props 的单向数据流串联父子、兄弟组件
- 利用“发布-订阅”模式驱动 React 数据在任意组件间流动
使用 Context API 维护全局状态
Context API 是 React 官方提供的一种组件树全局通信的方式
从编码的角度认识“三要素”
const AppContext = React.createContext(defaultValue)
const [Provider, Consume] = AppContext
新的 Context API 解决了什么问题
过时的 Context API 存在什么问题
第三方数据流框架“课代表”：初探 Redux
随着应用的复杂度不断提升
需要维护的状态越来越多
组件间的关系也越来越难以处理的时候
我们就需要请出 Redux 来帮忙
什么是 Redux
Redux 是 JavaScript 状态容器，它提供可预测的状态管理。
Redux 是如何帮助 React 管理数据的
- store 是一个单一的数据源，而且是只读的
- action 是对变化的描述
