// 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...