Context被翻译为上下文，在编程领域，这是一个经常会接触到的概念，React中也有。
在React的官方文档中，Context被归类为高级部分(Advanced)，属于React的高级API，但官方并不建议在稳定版的App中使用Context。
The vast majority of applications do not need to use content.
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。事实上，很多优秀的React组件都通过Context来完成自己的功能，比如react-redux的
今天就想跟大家聊一聊，我在开发当中，所认识到的这个Context，以及我是如何使用它来进行组件开发的。
注：本文中所有提到的App皆指Web端App。
官方对于Context的定义
React文档官网并未对Context给出“是什么”的定义，更多是描述使用的Context的场景，以及如何使用Context。
官网对于使用Context的场景是这样描述的：
In Some Cases, you want to pass data through the component tree without having to pass the props down manuallys at every level. you can do this directly in React with the powerful "context" API.
简单说就是，当你不想在组件树中通过逐层传递props或者state的方式来传递数据时，可以使用Context来实现跨层级的组件数据传递。
使用props或者state传递数据，数据自顶下流。
使用Context，可以跨越组件进行数据传递。
如果要Context发挥作用，需要用到两种组件，一个是Context生产者(Provider)，通常是一个父节点，另外是一个Context的消费者(Consumer)，通常是一个或者多个子节点。所以Context的使用基于生产者消费者模式。
对于父组件，也就是Context生产者，需要通过一个静态属性childContextTypes声明提供给子组件的Context对象的属性，并实现一个实例getChildContext方法，返回一个代表Context的纯对象 (plain object) 。
import React from 'react'
import PropTypes from 'prop-types'
class MiddleComponent extends React.Component {
render () {
return
而对于Context的消费者，通过如下方式访问父组件提供的Context。
import React from 'react'
import PropTypes from 'prop-types'
class ChildComponent extends React.Component {
// 声明需要使用的Context属性
static cOntextTypes= {
propA: PropTypes.string
}
render () {
const {
propA,
methodA
} = this.context
console.log(`context.propA = ${propA}`) // context.propA = propA
console.log(`context.methodA = ${methodA}`) // context.methodA = undefined
return ...
}
}
子组件需要通过一个静态属性contextTypes声明后，才能访问父组件Context对象的属性，否则，即使属性名没写错，拿到的对象也是undefined。
对于无状态子组件(Stateless Component)，可以通过如下方式访问父组件的Context
import React from 'react'
import PropTypes from 'prop-types'
const ChildCompOnent= (props, context) => {
const {
propA
} = context
console.log(`context.propA = ${propA}`) // context.propA = propA
return ...
}
ChildComponent.cOntextProps= {
propA: PropTypes.string
}
而在接下来的发行版本中，React对Context的API做了调整，更加明确了生产者消费者模式的使用方式。
import React from 'react';
import ReactDOM from 'react-dom';
const ThemeCOntext= React.createContext({
background: 'red',
color: 'white'
});
通过静态方法React.createContext()创建一个Context对象，这个Context对象包含两个组件，
class App extends React.Component {
render () {
return (
);
}
}
class Header extends React.Component {
render () {
return (
);
}
}
class Title extends React.Component {
render () {
return (
{cOntext=> (
{this.props.children}
)}
);
}
}
可见，Context的新API更加贴近React的风格。
实际上，除了实例的context属性(this.context)，React组件还有很多个地方可以直接访问父组件提供的Context。比如构造方法：
比如生命周期：
对于面向函数的无状态组件，可以通过函数的参数直接访问组件的Context。
const StatelessCompOnent= (props, context) => ( ...... )
以上是Context的基础，更具体的指南内容可参见这里
OK，说完基础的东西，现在聊一聊我对React的Context的理解。
使用React的开发者都知道，一个React App本质就是一棵React组件树，每个React组件相当于这棵树上的一个节点，除了App的根节点，其他每个节点都存在一条父组件链。
例如上图，
这些以树状连接的组件节点，实际上也组成了一棵Context树，每个节点的Context，来自父组件链上所有组件节点通过getChildContext()所提供的Context对象组合而成的对象。
有了解JS作用域链概念的开发者应该都知道，JS的代码块在执行期间，会创建一个相应的作用域链，这个作用域链记录着运行时JS代码块执行期间所能访问的活动对象，包括变量和函数，JS程序通过作用域链访问到代码块内部或者外部的变量和函数。
假如以JS的作用域链作为类比，React组件提供的Context对象其实就好比一个提供给子组件访问的作用域，而Context对象的属性可以看成作用域上的活动对象。由于组件的Context由其父节点链上所有组件通过getChildContext()返回的Context对象组合而成，所以，组件通过Context是可以访问到其父组件链上所有节点组件提供的Context的属性。
所以，我借鉴了JS作用域链的思路，把Context当成是组件的作用域来使用。
不过，作为组件作用域来看待的Context与常见的作用域的概念 (就我个人目前接触到的编程语言而言) 是有所区别的。我们需要关注Context的可控性和影响范围。
在我们平时的开发中，用到作用域或者上下文的场景是很常见，很自然，甚至是无感知的，然而，在React中使用Context并不是那么容易。父组件提供Context需要通过childContextTypes进行“声明”，子组件使用父组件的Context属性需要通过contextTypes进行“申请”，所以，我认为React的Context是一种“带权限”的组件作用域。
这种“带权限”的方式有何好处？就我个人的理解，首先是保持框架API的一致性，和propTypes一样，使用声明式编码风格。另外就是，可以在一定程度上确保组件所提供的Context的可控性和影响范围。
React App的组件是树状结构，一层一层延伸，父子组件是一对多的线性依赖。随意的使用Context其实会破坏这种依赖关系，导致组件之间一些不必要的额外依赖，降低组件的复用性，进而可能会影响到App的可维护性。
通过上图可以看到，原本线性依赖的组件树，由于子组件使用了父组件的Context，导致
在我看来，通过Context暴露数据或者API不是一种优雅的实践方案，尽管react-redux是这么干的。因此需要一种机制，或者说约束，去降低不必要的影响。
通过childContextTypes和contextTypes这两个静态属性的约束，可以在一定程度保障，只有组件自身，或者是与组件相关的其他子组件才可以随心所欲的访问Context的属性，无论是数据还是函数。因为只有组件自身或者相关的子组件可以清楚它能访问Context哪些属性，而相对于那些与组件无关的其他组件，无论是内部或者外部的 ，由于不清楚父组件链上各父组件的childContextTypes“声明”了哪些Context属性，所以没法通过contextTypes“申请”相关的属性。所以我理解为，给组件的作用域Context“带权限”，可以在一定程度上确保Context的可控性和影响范围。
在开发组件过程中，我们应该时刻关注这一点，不要随意的使用Context。
作为React的高级API，React并不推荐我们优先考虑使用Context。我的理解是：
简而言之，只要你能确保Context是可控的，使用Context并无大碍，甚至如果能够合理的应用，Context其实可以给React组件开发带来很强大的体验。
官方所提到Context可以用来进行跨组件的数据通信。而我，把它理解为，好比一座桥，作为一种作为媒介进行数据共享。数据共享可以分两类：App级与组件级。
App根节点组件提供的Context对象可以看成是App级的全局作用域，所以，我们利用App根节点组件提供的Context对象创建一些App级的全局数据。现成的例子可以参考react-redux，以下是
export function createProvider(storeKey = 'store', subKey) {
const subscriptiOnKey= subKey || `${storeKey}Subscription`
class Provider extends Component {
getChildContext() {
return { [storeKey]: this[storeKey], [subscriptionKey]: null }
}
constructor(props, context) {
super(props, context)
this[storeKey] = props.store;
}
render() {
return Children.only(this.props.children)
}
}
// ......
Provider.propTypes = {
store: storeShape.isRequired,
children: PropTypes.element.isRequired,
}
Provider.childCOntextTypes= {
[storeKey]: storeShape.isRequired,
[subscriptionKey]: subscriptionShape,
}
return Provider
}
export default createProvider()
App的根组件用
如果组件的功能不能单靠组件自身来完成，还需要依赖额外的子组件，那么可以利用Context构建一个由多个子组件组合的组件。例如，react-router。
react-router的
下面截取
// Router.js
/**
* The public API for putting history on context.
*/
class Router extends React.Component {
static propTypes = {
history: PropTypes.object.isRequired,
children: PropTypes.node
};
static cOntextTypes= {
router: PropTypes.object
};
static childCOntextTypes= {
router: PropTypes.object.isRequired
};
getChildContext() {
return {
router: {
...this.context.router,
history: this.props.history,
route: {
location: this.props.history.location,
match: this.state.match
}
}
};
}
// ......
componentWillMount() {
const { children, history } = this.props;
// ......
this.unlisten = history.listen(() => {
this.setState({
match: this.computeMatch(history.location.pathname)
});
});
}
// ......
}
尽管源码还有其他的逻辑，但
// Link.js /** * The public API for rendering a history-aware . */ class Link extends React.Component { // ...... static cOntextTypes= { router: PropTypes.shape({ history: PropTypes.shape({ push: PropTypes.func.isRequired, replace: PropTypes.func.isRequired, createHref: PropTypes.func.isRequired }).isRequired }).isRequired }; handleClick = event => { if (this.props.onClick) this.props.onClick(event); if ( !event.defaultPrevented && event.button === 0 && !this.props.target && !isModifiedEvent(event) ) { event.preventDefault(); // 使用组件提供的router实例 const { history } = this.context.router; const { replace, to } = this.props; if (replace) { history.replace(to); } else { history.push(to); } } }; render() { const { replace, to, innerRef, ...props } = this.props; // ... const { history } = this.context.router; const location = typeof to === "string" &＃63; createLocation(to, null, null, history.location) : to; const href = history.createHref(location); return ( ); } }
的核心就是渲染标签，拦截标签的点击事件，然后通过
// Route.js
/**
* The public API for matching a single path and rendering.
*/
class Route extends React.Component {
// ......
state = {
match: this.computeMatch(this.props, this.context.router)
};
// 计算匹配的路径，匹配的话，会返回一个匹配对象，否则返回null
computeMatch(
{ computedMatch, location, path, strict, exact, sensitive },
router
) {
if (computedMatch) return computedMatch;
// ......
const { route } = router;
const pathname = (location || route.location).pathname;
return matchPath(pathname, { path, strict, exact, sensitive }, route.match);
}
// ......
render() {
const { match } = this.state;
const { children, component, render } = this.props;
const { history, route, staticContext } = this.context.router;
const location = this.props.location || route.location;
const props = { match, location, history, staticContext };
if (component) return match &＃63; React.createElement(component, props) : null;
if (render) return match &＃63; render(props) : null;
if (typeof children === "function") return children(props);
if (children && !isEmptyChildren(children))
return React.Children.only(children);
return null;
}
}
通过上述的分析，可以看出，整个react-router其实就是围绕着
之前，通过Context开发过一个简单的组件，插槽分发组件。本章就借着这个插槽分发组件的开发经历，聊聊如何使用Context进行组件的开发。
首先说说什么是插槽分发组件，这个概念最初是在Vuejs中认识的。插槽分发是一种通过组件的组合，将父组件的内容插入到子组件模板的技术，在Vuejs中叫做Slot。
为了让大家更加直观的理解这个概念，我从Vuejs搬运了一段关于插槽分发的Demo。
对于提供的插槽的组件
我是子组件的标题
只有在没有要分发的内容时显示
对于父组件，模板如下：
我是父组件的标题
这是一些初始内容
这是更多的初始内容
最终渲染的结果：
我是父组件的标题
我是子组件的标题
这是一些初始内容
这是更多的初始内容
可以看到组件
Vuejs还支持具名插槽。
例如，一个布局组件
而在父组件模板中：
这里可能是一个页面标题
主要内容的一个段落。
另一个段落。
这里有一些联系信息
最终渲染的结果：
这里可能是一个页面标题
主要内容的一个段落。
另一个段落。
插槽分发的好处体现在，它可以让组件具有可抽象成模板的能力。组件自身只关心模板结构，具体的内容交给父组件去处理，同时，不打破HTML描述DOM结构的语法表达方式。我觉得这是一项很有意义的技术，可惜，React对于这项技术的支持不是那么友好。于是我便参考Vuejs的插槽分发组件，开发了一套基于React的插槽分发组件，可以让React组件也具模板化的能力。
对于
class AppLayout extends React.Component {
static displayName = 'AppLayout'
render () {
return (
)
}
}
在外层使用时，可以写成这样：
这里可能是一个页面标题
主要内容的一个段落。
另一个段落。
这里有一些联系信息
根据前面所想的，先整理一下实现思路。
不难看出，插槽分发组件需要依靠两个子组件——插槽组件
显然，这里遇到了一个问题，
对于
class AppLayout extends React.Component {
static displayName = 'AppLayout'
render () {
return (
)
}
}
在外层使用时，写成这样：
这里可能是一个页面标题
主要内容的一个段落。
另一个段落。
这里有一些联系信息
无论是
前面提到了
由于
对于
class AppLayout extends React.Component {
static childCOntextTypes= {
requestAddOnRenderer: PropTypes.func
}
// 用于缓存每个
)
}
}
// props, context
const Slot = ({ name, children }, { requestAddOnRenderer }) => {
const addOnRenderer= requestAddOnRenderer(name)
return (addOnRenderer && addOnRenderer()) ||
children ||
null
}
Slot.displayName = 'Slot'
Slot.cOntextTypes= { requestAddOnRenderer: PropTypes.func }
Slot.propTypes = { name: PropTypes.string }
Slot.defaultProps = { name: '$$default' }
可以看到
const AddOn = () => null
AddOn.propTypes = { slot: PropTypes.string }
AddOn.defaultTypes = { slot: '$$default' }
AddOn.displayName = 'AddOn'
通过上文的代码，基本将
我给这个组件命名为SlotProvider
function getDisplayName (component) {
return component.displayName || component.name || 'component'
}
const slotProviderHoC = (WrappedComponent) => {
return class extends React.Component {
static displayName = `SlotProvider(${getDisplayName(WrappedComponent)})`
static childCOntextTypes= {
requestAddOnRenderer: PropTypes.func
}
// 用于缓存每个
使用React的高阶组件对原来的
import { SlotProvider } from './SlotProvider.js'
class AppLayout extends React.Component {
static displayName = 'AppLayout'
render () {
return (
)
}
}
export default SlotProvider(AppLayout)
通过以上的经历，可以看到，当设计开发一个组件时，
这时我们就需要借助一个中间者作为媒介来共享数据，相比额外引入redux这些第三方模块，直接使用Context可以更优雅。
使用新版的Context API对之前的插槽分发组件进行改造。
// SlotProvider.js
function getDisplayName (component) {
return component.displayName || component.name || 'component'
}
export const SlotCOntext= React.createContext({
requestAddOnRenderer: () => {}
})
const slotProviderHoC = (WrappedComponent) => {
return class extends React.Component {
static displayName = `SlotProvider(${getDisplayName(WrappedComponent)})`
// 用于缓存每个
)
}
}
}
export const SlotProvider = slotProviderHoC
移除了之前的childContextTypes和getChildContext()，除了局部的调整，整体核心的东西没有大变化。
// Slot.js
import { SlotContext } from './SlotProvider.js'
const Slot = ({ name, children }) => {
return (
{(context) => {
const addOnRenderer= requestAddOnRenderer(name)
return (addOnRenderer && addOnRenderer()) ||
children ||
null
}}
)
}
Slot.displayName = 'Slot'
Slot.propTypes = { name: PropTypes.string }
Slot.defaultProps = { name: '$$default' }
由于之前就按照生产者消费者的模式来使用Context，加上组件自身也比较简单，因此使用新的API进行改造后，差别不大。
以上是我的分享内容，如有不足或者错误的地方，欢迎批评指正。
Context - https://reactjs.org/docs/context.html
React 16.3来了：带着全新的Context API - http://cnodejs.org/topic/5a7bd5c4497a08f571384f03
Content Distribution with Slots - https://vuejs.org/v2/guide/components.html#Content-Distribution-with-Slots
到此这篇关于聊一聊我对 React Context 的理解以及应用的文章就介绍到这了,更多相关React Context 内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有 
