React16源码: context用法与createContext源码实现

关注

原创最新推荐文章于 2026-08-20 15:49:50 发布 1.8k 阅读 AI 写同款· GEO 优化 ›

洞悉细节！react 16.8.6源码分析-4 children遍历前言作为一个前端页面仔和需求粉碎机，在日常的工作中重复雷同的业务需求，能够获得的提高是很有限的。要想跳出此山中，开阔新视野，笔者墙裂建议大家阅读市面上顶尖开源库的源码。这是学习和掌握js语言特性的绝佳机会(前端发展到现在，大型应用高度依赖框架，正常情况下普通开发者是没有机会接触底层的语言特性)，同时也是深刻理解框架底层思维的契机。这里笔者选择react第一个开刀，市面上不少关于react源码分析的文章要么过于老旧，要么只截取部分代码或者是伪代码，笔者这里将选取react的16.8.6版本作为示例，从第0行阅读详情

context

1 ）概述

在react的设计中，组件与组件之间的通信通常是
- 父组件通过 props 给子组件传递子组件需要的属性
- 父组件通过传递一些回调函数给子组件
- 让子组件在某些特定的时候，可以调用一些父组件的特性
这种情况，会存在一个问题
- 就是react的应用中组件和组件之间并不一定只有父子关系
- 还会存在着像父子嵌套多层之后，第一层和最下层的组件
- 他们之间是一个主孙的一个关系
- 他们中间会隔着好几层不同的组件，如果通过props进行一个传递，是不太现实的
- 还有就是中间的那几层组件，不一定是我们自己写的
- 中间的组件要去传递这个 props，其实是完全没有意义的事情
所以，react 提供了一个 context 的一个使用方式
- 在上级组件中，我们提供了一个 context 对象之后
- 只要是在它下面渲染的组件都可以通过 context 这个属性去获取到它提供的这部分内容
- 以此达到一个跨越多层组件传递信息的一个功能
context 有两种实现方式
- 第一种，是通过老的 context 的 API 叫做 childContextTypes
  - 老的 childContextTypes 在react17 这个大版本发布的时候被废弃
  - 历史原因，用的还挺多
- 第二种, 是通过新版提供的 createContext 这个API
  - 这块下面会分析下源码

用法示例

1 ）示例演示

这个示例，演示了新旧两个 api 的用法

import React from 'react'
import PropTypes from 'prop-types'

const { Provider, Consumer } = React.createContext('default')

// 定义一个父组件 作为 最外层
class Parent extends React.Component {
  state = {
    childContext: '123',
    newContext: '456',
  }
  // react 静态方法 api
  getChildContext() {
    return { value: this.state.childContext, a: 'aaaaa' }
  }
  render() {
    return (
      <>
        <div>
          <label>childContext:</label>
          <input
            type="text"
            value={this.state.childContext}
            onChange={e => this.setState({ childContext: e.target.value })}
          />
        </div>
        <div>
          <label>newContext:</label>
          <input
            type="text"
            value={this.state.newContext}
            onChange={e => this.setState({ newContext: e.target.value })}
          />
        </div>
        {/* 基于 Provider来传递 */}
        <Provider value={this.state.newContext}>{this.props.children}</Provider>
      </>
    )
  }
}

// 定义第二个父组件 作为 中间层
class Parent2 extends React.Component {
  // { value: this.state.childContext, a: 'bbbbb' }
  getChildContext() {
    return { a: 'bbbbb' }
  }

  render() {
    return this.props.children
  }
}

// 定义第一个子组件 内部使用 Consumer
function Child1(props, context) {
  console.log(context)
  return <Consumer>{value => <p>newContext: {value}</p>}</Consumer>
}

// 声明子组件需要的 props
Child1.contextTypes = {
  value: PropTypes.string,
}

// 定义第二个子组件
class Child2 extends React.Component {
  render() {
    return (
      <p>
        childContext: {this.context.value} {this.context.a}
      </p>
    )
  }
}

// Child2.contextType = Consumer
// 声明 子组件2 需要的 props
Child2.contextTypes = {
  value: PropTypes.string,
  a: PropTypes.string,
}

// 父组件不声明，子组件无法获取 props
Parent.childContextTypes = {
  value: PropTypes.string,
  a: PropTypes.string,
}

// 父组件不声明，子组件无法获取 props
Parent2.childContextTypes = {
  a: PropTypes.string,
}

// 最终的组件树，不同组件的嵌套
export default () => (
  <Parent>
    <Parent2>
      <Child1 />
      <Child2 />
    </Parent2>
  </Parent>
)

2 ）关于 childContextTypes 旧版API的说明

主要以 Child2 组件来说明
上级组件中声明这个 getChildContext 这个方法
然后return的这个对象, 就是作为子组件当中能够获取这个 context 的对象
但是有一点必须要注意，就是父组件必须要声明 childContextTypes, 即: Parent.childContextTypes
```
  Parent.childContextTypes = {
    value: PropTypes.string,
    a: PropTypes.string,
  }
```
上层组件是必须要声明的
如果不声明，它提供的这个 context ，子组件是无法获取到的
想要获取上层组件提供的 context，需要在子组件 Child2 当中

声明自己需要的 contextTypes, 例如

 Child2.contextTypes = {
   value: PropTypes.string,
   a: PropTypes.string,
 }

它的内容也是跟上层组件的 childContextTypes 是一样
两者区别是: 有或没有子组件
在这个渲染的过程中，比如这个 Child2 组件，希望获取父层组件中提供的 context 里面的某几个属性
Chid 自己就需要去声明使用几个属性，为何这么做呢
- 在react当中，它的上层组件不一定只有一个
- 它上层组件中提供的 context 也不一定只有一个
- 它们是会有一个 merge 的一个过程的
- 所以在很多属性中 react 要知道你想要获取上层组件当中提供的context里面的哪几个属性
- 所以要通过这种方式进行一个声明

3 ）关于 createContext 新版API的分析

通过 react.createContext，它返回了一个对象

const { Provider, Consumer } = React.createContext('default')

这个对象里面包含了 Provider 和 Consumer，是一个 context 提供方和 context 的订阅方
这两个都是组件，我们通过在 Parent 这边我们提供了Provider, 然后上面指定 value
```
<Provider value={this.state.newContext}>{this.props.children}</Provider>
```
- 这个 value 就是 context，即提供的context的属性信息
- 在它的子树下面，只需要在想要用到context的地方
- 通过这个 Consumer 组件 (它传入的是一个回调方法)
- 这个方法是一个function Component，它接收它的一个value
- 并且把这个想要渲染的东西渲染出来就可以了
```
// 声明子组件需要的 props
Child1.contextTypes = {
 value: PropTypes.string,
}
```
所以Provider 和 Consumer 是一一对应的关系
在上层组件里面定义之后，子组件里面你想要在哪个地方用到这个属性
你再去专门用这个组件去进行一个渲染就可以了

4 ）为什么要弃用老的API要改成这种新的API

因老的API它对于context提供方，它下层的所有组件的影响太大了
它会导致它下层的所有组件, 即便在没有任何更新的情况下，它每一次更新的过程当中
仍然要进行完整的渲染，所以对性能的损耗会非常大

createContext 源码分析

定位到 reactContext.js

/**
 * Copyright (c) Facebook, Inc. and its affiliates.
 *
 * This source code is licensed under the MIT license found in the
 * LICENSE file in the root directory of this source tree.
 *
 * @flow
 */

import {REACT_PROVIDER_TYPE, REACT_CONTEXT_TYPE} from 'shared/ReactSymbols';

import type {ReactContext} from 'shared/ReactTypes';

import warningWithoutStack from 'shared/warningWithoutStack';
import warning from 'shared/warning';

export function createContext<T>(
  defaultValue: T,
  calculateChangedBits: ?(a: T, b: T) => number,
): ReactContext<T> {
  if (calculateChangedBits === undefined) {
    calculateChangedBits = null;
  } else {
    if (__DEV__) {
      warningWithoutStack(
        calculateChangedBits === null ||
          typeof calculateChangedBits === 'function',
        'createContext: Expected the optional second argument to be a ' +
          'function. Instead received: %s',
        calculateChangedBits,
      );
    }
  }

  const context: ReactContext<T> = {
    $$typeof: REACT_CONTEXT_TYPE,
    _calculateChangedBits: calculateChangedBits,
    // As a workaround to support multiple concurrent renderers, we categorize
    // some renderers as primary and others as secondary. We only expect
    // there to be two concurrent renderers at most: React Native (primary) and
    // Fabric (secondary); React DOM (primary) and React ART (secondary).
    // Secondary renderers store their context values on separate fields.
    _currentValue: defaultValue,
    _currentValue2: defaultValue,
    // These are circular
    Provider: (null: any),
    Consumer: (null: any),
  };

  context.Provider = {
    $$typeof: REACT_PROVIDER_TYPE,
    _context: context,
  };

  let hasWarnedAboutUsingNestedContextConsumers = false;
  let hasWarnedAboutUsingConsumerProvider = false;

  if (__DEV__) {
    // A separate object, but proxies back to the original context object for
    // backwards compatibility. It has a different $$typeof, so we can properly
    // warn for the incorrect usage of Context as a Consumer.
    const Consumer = {
      $$typeof: REACT_CONTEXT_TYPE,
      _context: context,
      _calculateChangedBits: context._calculateChangedBits,
    };
    // $FlowFixMe: Flow complains about not setting a value, which is intentional here
    Object.defineProperties(Consumer, {
      Provider: {
        get() {
          if (!hasWarnedAboutUsingConsumerProvider) {
            hasWarnedAboutUsingConsumerProvider = true;
            warning(
              false,
              'Rendering <Context.Consumer.Provider> is not supported and will be removed in ' +
                'a future major release. Did you mean to render <Context.Provider> instead?',
            );
          }
          return context.Provider;
        },
        set(_Provider) {
          context.Provider = _Provider;
        },
      },
      _currentValue: {
        get() {
          return context._currentValue;
        },
        set(_currentValue) {
          context._currentValue = _currentValue;
        },
      },
      _currentValue2: {
        get() {
          return context._currentValue2;
        },
        set(_currentValue2) {
          context._currentValue2 = _currentValue2;
        },
      },
      Consumer: {
        get() {
          if (!hasWarnedAboutUsingNestedContextConsumers) {
            hasWarnedAboutUsingNestedContextConsumers = true;
            warning(
              false,
              'Rendering <Context.Consumer.Consumer> is not supported and will be removed in ' +
                'a future major release. Did you mean to render <Context.Consumer> instead?',
            );
          }
          return context.Consumer;
        },
      },
    });
    // $FlowFixMe: Flow complains about missing properties because it doesn't understand defineProperty
    context.Consumer = Consumer;
  } else {
    context.Consumer = context;
  }

  if (__DEV__) {
    context._currentRenderer = null;
    context._currentRenderer2 = null;
  }

  return context;
}

定位到 createContext, 它接收的是一个 defaultValue 和 calculateChangeBits方法
- calculateChangeBits方法是用来计算新老context它们的一个变化的
在这里，它声明了一个context对象, 这个对象跟之前的 ReactElement 非常的像
- 它有一个 $$typeof, 这里的 $$typeof 跟 ReactElement 里面的 $$typeof 是不一样的
下面有这两个属性 _currentValue, _currentValue2
- 这两个属性它们的用处是一样的，使用的地方会不一样，比如说，不同平台里面会不一样
- 它的 _currentValue 是用来记录 Provider上面提供的这个 value
- 在有变化的情况下，它就会更新到这个 _currentValue 上面，这就是用来记录最新的context的值的
下面会有一个 Provider和 Consumer
然后再接下去, 有一个 context.Provider 这个对象
```
 context.Provider = {
   $$typeof: REACT_PROVIDER_TYPE,
   _context: context,
 };
```
- 这个_context指向这个context的对象
忽略DEV相关的判断代码
在最后我们看到 context.Consumer = context
- 也就是说 Consumer是指向这个对象自己的
- 在Consumer进行渲染的时候，它要去获取这个value
- 直接从它本身上面去获取到这个 _currentValue
- 就可以拿到最新的 context 的值了，然后再调用Consumer 的回调方法把它传进去
- 就可以渲染出最新的内容
所以这就是它的一个基本的实现原理。
整个context 新的contextAPI的一个源码不是特别复杂，但是整个通信过程并不止这一点
在这里，主要是弄清楚 Provider 和 Consumer 的关系
需要注意的是
- 返回的这个 Provider 和 Consumer，它们里面都有 $$typeof
- 它们并不是用替代 ReactElement 里面的 $$typeof
- 因为它返回的这个对象是整体, 是作为 ReactElement 里面的 type 属性去存储的
- 所以跟这边的 $$typeof 是完全没有任何关系的
- 也就是说 type 里面它还有一个 $$typeof, 表明它是一个context的 Provider，或 Consumer
- 这个问题在前文也有提过