// 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 ? React.createElement(component, props) : null;

    if (render) return match ? render(props) : null;

    if (typeof children === "function") return children(props);

    if (children && !isEmptyChildren(children))
      return React.Children.only(children);

    return null;
  }
}

有一部分源码与相似，可以实现路由的嵌套，但其核心是通过Context共享的router，判断是否匹配当前路由的路径，然后渲染组件。

通过上述的分析，可以看出，整个react-router其实就是围绕着的Context来构建的。

之前，通过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 (
      

        

          
        
        

          
        
        
      
    )
  }
}

在外层使用时，写成这样：

  
    
这里可能是一个页面标题
  
  
    
主要内容的一个段落。
      
另一个段落。
  
  
    
这里有一些联系信息
  

无论是还是，其实都在的作用域内。是组件render()方法返回的组件节点，而则是的children节点，所以，可以将视为与的桥梁的角色。那么，通过什么给和建立联系呢？这里就用到本文的主角——Context。接下来的问题就是，如何使用Context给和建立联系？

前面提到了这座桥梁。在外层组件，负责通过收集为插槽填充的内容。自身借助Context定义一个获取填充内容的接口。在渲染的时候，因为是渲染的节点，所以，可以通过Context获取到定义的获取填充内容的接口，然后通过这个接口，获取到填充内容进行渲染。

由于是的children节点，并且是特定的组件，我们可以通过name或者displayName识别出来，所以，在渲染之前，也就是render()的return之前，对children进行遍历，以slot的值作为key，将每一个的children缓存下来。如果没有设置slot，那么将其视为给非具名的填充内容，我们可以给这些非具名的插槽定一个key，比如叫$$default。

对于，代码大致如下：

class AppLayout extends React.Component {
  
  static childContextTypes = {
    requestAddOnRenderer: PropTypes.func
  }
  
  // 用于缓存每个的内容
  addOnRenderers = {}
  
  // 通过Context为子节点提供接口
  getChildContext () {
    const requestAddOnRenderer = (name) => {
      if (!this.addOnRenderers[name]) {
        return undefined
      }
      return () => (
        this.addOnRenderers[name]
      )
    }
    return {
      requestAddOnRenderer
    }
  }

  render () {
    const {
      children,
      ...restProps
    } = this.props

    if (children) {
      // 以k-v的方式缓存的内容
      const arr = React.Children.toArray(children)
      const nameChecked = []
      this.addOnRenderers = {}
      arr.forEach(item => {
        const itemType = item.type
        if (item.type.displayName === "AddOn") {
          const slotName = item.props.slot || "$$default"
          // 确保内容唯一性
          if (nameChecked.findIndex(item => item === stubName) !== -1) {
            throw new Error(`Slot(${slotName}) has been occupied`)
          }
          this.addOnRenderers[stubName] = item.props.children
          nameChecked.push(stubName)
        }
      })
    }

    return (
      

        

          
        
        

          
        
        
      
    )
  }
}

定义了一个Context接口requestAddOnRenderer()，requestAddOnRenderer()接口根据name返回一个函数，这个返回的函数会根据name访问addOnRenderers的属性，addOnRenderers就是的内容缓存对象。

的实现很简单，代码如下：

//            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" }

可以看到通过context获取到提供的接口requestAddOnRenderer()，最终渲染的主要对象就是缓存在中的的内容。如果没有获取到指定的的内容，则渲染自身的children。

更简单：

const AddOn = () => null

AddOn.propTypes = { slot: PropTypes.string }
AddOn.defaultTypes = { slot: "$$default" }
AddOn.displayName = "AddOn"

不做任何事情，仅仅返回null，它的作用就是让缓存分发给插槽的内容。

通过上文的代码，基本将改造成了一个具备插槽分发能力的组件，但是很明显的，并不具备通用性，我们可以将它提升成一个独立通用的组件。

我给这个组件命名为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
    }
  
    // 用于缓存每个的内容
    addOnRenderers = {}
  
    // 通过Context为子节点提供接口
    getChildContext () {
      const requestAddOnRenderer = (name) => {
        if (!this.addOnRenderers[name]) {
          return undefined
        }
        return () => (
          this.addOnRenderers[name]
        )
      }
      return {
        requestAddOnRenderer
      }
    }

    render () {
      const {
        children,
        ...restProps
      } = this.props

      if (children) {
        // 以k-v的方式缓存的内容
        const arr = React.Children.toArray(children)
        const nameChecked = []
        this.addOnRenderers = {}
        arr.forEach(item => {
          const itemType = item.type
          if (item.type.displayName === "AddOn") {
            const slotName = item.props.slot || "$$default"
            // 确保内容唯一性
            if (nameChecked.findIndex(item => item === stubName) !== -1) {
              throw new Error(`Slot(${slotName}) has been occupied`)
            }
            this.addOnRenderers[stubName] = item.props.children
            nameChecked.push(stubName)
          }
        })
      }
      
      return ()
    }
  }
}

export const SlotProvider = slotProviderHoC

使用React的高阶组件对原来的进行改造，将其转变为一个独立通用的组件。对于原来的，可以使用这个SlotProvider高阶组件，转换成一个具备插槽分发能力的组件。

import { SlotProvider } from "./SlotProvider.js"

class AppLayout extends React.Component {
  static displayName = "AppLayout"
  
  render () {
    return (
      

        

          
        
        

          
        
        
      
    )
  }
}

export default SlotProvider(AppLayout)

通过以上的经历，可以看到，当设计开发一个组件时，

组件可能需要由一个根组件和多个子组件一起合作来完成组件功能。比如插槽分发组件实际上需要SlotProvider与和一起配合使用，SlotProvider作为根组件，而和都算是子组件。

子组件相对于根组件的位置或者子组件之间的位置是不确定。对于SlotProvider而言，的位置是不确定的，它会处在被SlotProvider这个高阶组件所包裹的组件的模板的任何位置，而对于和，他们直接的位置也不确定，一个在SlotProvider包装的组件的内部，另一个是SlotProvider的children。

子组件之间需要依赖一些全局态的API或者数据，比如实际渲染的内容来自于SlotProvider收集到的的内容。

这时我们就需要借助一个中间者作为媒介来共享数据，相比额外引入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)})`

    // 用于缓存每个的内容
    addOnRenderers = {}
  
    requestAddOnRenderer = (name) => {
      if (!this.addOnRenderers[name]) {
        return undefined
      }
      return () => (
        this.addOnRenderers[name]
      )
    }

    render () {
      const {
        children,
        ...restProps
      } = this.props

      if (children) {
        // 以k-v的方式缓存的内容
        const arr = React.Children.toArray(children)
        const nameChecked = []
        this.addOnRenderers = {}
        arr.forEach(item => {
          const itemType = item.type
          if (item.type.displayName === "AddOn") {
            const slotName = item.props.slot || "$$default"
            // 确保内容唯一性
            if (nameChecked.findIndex(item => item === stubName) !== -1) {
              throw new Error(`Slot(${slotName}) has been occupied`)
            }
            this.addOnRenderers[stubName] = item.props.children
            nameChecked.push(stubName)
          }
        })
      }
      
      return (
        
          
        
      )
    }
  }
}

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进行改造后，差别不大。

相比props和state，React的Context可以实现跨层级的组件通信。

Context API的使用基于生产者消费者模式。生产者一方，通过组件静态属性childContextTypes声明，然后通过实例方法getChildContext()创建Context对象。消费者一方，通过组件静态属性contextTypes申请要用到的Context属性，然后通过实例的context访问Context的属性。

使用Context需要多一些思考，不建议在App中使用Context，但如果开发组件过程中可以确保组件的内聚性，可控可维护，不破坏组件树的依赖关系，影响范围小，可以考虑使用Context解决一些问题。

通过Context暴露API或许在一定程度上给解决一些问题带来便利，但个人认为不是一个很好的实践，需要慎重。

旧版本的Context的更新需要依赖setState()，是不可靠的，不过这个问题在新版的API中得以解决。

可以把Context当做组件的作用域来看待，但是需要关注Context的可控性和影响范围，使用之前，先分析是否真的有必要使用，避免过度使用所带来的一些副作用。

可以把Context当做媒介，进行App级或者组件级的数据共享。

设计开发一个组件，如果这个组件需要多个组件关联组合的，使用Context或许可以更加优雅。

以上是我的分享内容，如有不足或者错误的地方，欢迎批评指正。

Context - https://reactjs.org/docs/cont...

React 16.3来了：带着全新的Context API - http://cnodejs.org/topic/5a7b...

Content Distribution with Slots - https://vuejs.org/v2/guide/co...