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

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
  • 这个问题在前文也有提过