Context API 可以说是 React 中最有趣的一个特性了。一方面很多流行的框架（例如react-redux、mobx-react、react-router等）都在使用它；另一方面官方文档中却不推荐我们使用它。在 Context API 的文档中有下面这段话：
The vast majority of applications do not need to use context.
If you want your application to be stable, don’t use context. It is an experimental API and it is likely to break in future releases of React.
为何会出现这种情况呢？这还得让我们从现有版本 Context API 要解决的问题已经它自身的缺陷说起。
现有版本 Context API 的使用场景以及缺陷
我们都知道在 React 中父子组件可以通过 props 自顶向下的传递数据。但是当组件深度嵌套时，从顶层组件向最内层组件传递数据就不那么方便了。手动在每一层组件上逐级传递 prop 不仅书写起来很繁琐同时还会为夹在中间的组件引入不必要的 prop。这时 Context API 就派上用场了。你只需要在外层组件上声明要传递给子组件的 Context：
class Parent extends React.Component {
getChildContext() {
return {color: "purple"};
}
}
Parent.childContextTypes = {
color: PropTypes.string
};然后就可以在任意一级子组件上访问 Context 里的内容了：
class Child extends React.Component {
render() {
return (
<p>
{this.context.color}
</p>
);
}
}
Child.contextTypes = {
color: PropTypes.string
};现有 Context API 虽然使用起来不算复杂，但当和 shouldComponentUpdate 搭配使用时就很容易出问题。
让我们通过一个小例子来简单说明，假设有以下组件结构：
<A>
<B>
<C />
</B>
</A>其中组件 A 会通过 getChildContext 设置 Context，组件 C 通过 this.context 读取 Context。
当组件 A 要更新 Context 的时候发生什么呢？
- 组件 A 通过
setState设置新的 Context 值同时触发子组件的 rerender。 - 组件 B rerender。
- 组件 C rerender，并在自己的 render 方法中拿到更新后的Context。
整个流程看起来好像没什么问题。如果我们在组件 B 上定义了 shouldComponentUpdate 会发生什么呢？
- 组件 A 通过
setState设置新的 Context 值同时触发子组件的 rerender。 - 组件 B 执行
shouldComponetUpdate，由于组件 B 自身并不依赖 Context，所以shouldComponetUpdate检测到 state 与 prop 均未变化因此返回false。无需重新 render。 - 由于 B 组件没有 rerender。这导致组件 C 也不会rerender，因此也就无法获取到最新的 Context 值。
由于 shouldComponentUpdate 是一个 React 开发人员经常使用的优化方法。所以如果代码里使用了现有的 Context API 很大概率会遇到上述问题。
那么有没有解决方案可以让现有 Context API 和 shouldComponetUpdate 完美配合呢？答案是有的。这篇文章里有详细的讨论。但该方案属于比较 hack 的方式，且对新手并不友好。所以 React 的官方文档里并不建议我们使用现有的 Context API。
新版 Context API
这种情况在去年 12 月 7 号迎来了改变。@acdlite 在 reactjs/rfcs中发起了一个名为『New version of context』 的 PR。带来了全新的 Context API 提案。2 天后，包含新 Context API 具体实现的 PR 也提交到了 React 代码库。这两个 PR 都在今年 1 月 25 号被合并入各自的代码库。
首先让我们来看看新版 Context API 都由哪几部分组成：
React.createContext方法用于创建一个 Context 对象。该对象包含Provider和Consumer两个属性，分别为两个 React 组件。Provider组件。用在组件树中更外层的位置。它接受一个名为value的 prop，其值可以是任何 JavaScript 中的数据类型。Consumer组件。可以在Provider组件内部的任何一层使用。它接收一个名为children值为一个函数的 prop。这个函数的参数是Provider组件接收的那个valueprop 的值，返回值是一个 React 元素（一段 JSX 代码）。
用代码描述是这样的：
type Context<T> = {
Provider: Provider<T>,
Consumer: Consumer<T>,
};
interface React {
createContext<T>(defaultValue: T): Context<T>;
}
type Provider<T> = React.Component<{
value: T,
children?: React.Node,
}>;
type Consumer<T> = React.Component<{
children: (value: T) => React.Node,
}>;以下是一段基于新 Context API 编写的代码：
import React from "react";
import { render } from "react-dom";
const NameContext = React.createContext("Jack");;
class Hello extends React.PureComponent {
render() {
return (
<NameContext.Consumer>
{name => <h1>Hello *{name}* who come from the new Context API!</h1>}
</NameContext.Consumer>
);
}
}
class App extends React.Component {
constructor() {
super();
this.state = {
name: "Michael"
};
this.modify = this.modify.bind(this);
}
modify() {
this.setState({
name: this.state.name + "!"
});
}
render() {
return (
<div>
<button onClick={this.modify}>Modify Context Value</button>
<NameContext.Provider value={this.state.name}>
{this.props.children}
</NameContext.Provider>
</div>
);
}
}
render(
<App>
<Hello />
</App>,
document.getElementById("root")
);以下是这段代码的运行效果。
下面让我们结合这段代码来说一说新版 Context API 的几个特点：
Provider和Consumer必须来自同一次React.createContext调用。也就是说NameContext.Provider和AgeContext.Consumer是无法搭配使用的。React.createContext方法接收一个默认值作为参数。当Consumer外层没有对应的Provider时就会使用该默认值。Provider组件的valueprop 值发生变更时，其内部组件树中对应的Consumer组件会接收到新值并重新执行children函数。此过程不受shouldComponentUpdete方法的影响。前面的示例代码中，Hello组件继承自React.PureComponent但页面依然能正确显示足以说明这一点。Provider组件利用Object.is检测valueprop 的值是否有更新。注意Object.is和===的行为不完全相同。具体细节请参考Object.is的 MDN 文档页。Consumer组件接收一个函数作为childrenprop 并利用该函数的返回值生成组件树的模式被称为 Render Props 模式。详细介绍请参考相关 React 文档
以上就是关于 React 全新 Context API 的介绍了。按照计划，全新的 Context API 会随着 React 16.3.0 版本发布。如果你想现在就体验一把，可以通过以下命令安装 alpha 版本：
yarn add react@next react-dom@next
