這時，Provider組件開始工作

componentDidMount() {
  this._isMounted = true
  this.subscribe()
}

第一次加載，需要執(zhí)行subscribe

subscribe是什么呢，就是對redux的store執(zhí)行subscribe一個自定義函數(shù)，
這樣，每當(dāng)數(shù)據(jù)變動，這個函數(shù)便會執(zhí)行

subscribe() {
  const { store } = this.props
  // redux 的 store 訂閱
  // 訂閱后，每當(dāng)state改變 則自動執(zhí)行這個函數(shù)
  this.unsubscribe = store.subscribe(() => {
    // store.getState() 獲取最新的 state
    const newStoreState = store.getState()
    // 組件未加載，取消
    if (!this._isMounted) {
      return
    }
    // 比較state是否相等，全等的不更新
    this.setState(providerState => {
      if (providerState.storeState === newStoreState) {
        return null
      }
      return { storeState: newStoreState }
    })
  })
  /* ... */
}

看到嗎，這個自定義函數(shù)非常簡單，每次收到數(shù)據(jù)，進(jìn)行全等比較，不等則更新數(shù)據(jù)。

這個組件的另2個生命周期函數(shù)：

componentWillUnmount() {
  if (this.unsubscribe) this.unsubscribe()
  this._isMounted = false
}

componentDidUpdate(prevProps) {
  // 比較store是否相等,如果相等則跳過
  if (this.props.store !== prevProps.store) {
    // 取消訂閱之前的，再訂閱現(xiàn)在的(因為數(shù)據(jù)(store)不同了)
    if (this.unsubscribe) this.unsubscribe()
    this.subscribe()
  }
}

這2段的意思就是，每當(dāng)數(shù)據(jù)變了，就取消上一次數(shù)據(jù)的訂閱，在訂閱本次的數(shù)據(jù)，
當(dāng)要銷毀組件，取消訂閱。

一段題外話(可跳過)：
這個邏輯用Hooks的useEffect簡直完美匹配！
useEffect(()=>{
  subscribe()
  return ()=>{
    unSubscribe()
  }
},props.data)
這段的意思就是，當(dāng)props.data發(fā)生改變，執(zhí)行unSubscribe()，再執(zhí)行subscribe()。
邏輯完全一致有沒有！

最后的render：

這里Context就是React.createContext(null)

  {this.props.children}

到這里我稱為react-redux的第一階段。

一個小總結(jié)，第一階段就做了1件事：

定義了Provider組件，內(nèi)部訂閱了store。

到主菜了，先看它的export

export default createConnect()

一看，我們應(yīng)該有個猜測，這貨createConnect是個高階函數(shù)。

看看它的參數(shù)吧。

export function createConnect({
  connectHOC = connectAdvanced,
  mapStateToPropsFactories = defaultMapStateToPropsFactories,
  mapDispatchToPropsFactories = defaultMapDispatchToPropsFactories,
  mergePropsFactories = defaultMergePropsFactories,
  selectorFactory = defaultSelectorFactory
} = {}) {
  /* ... */
}

題外話：一個編寫默認(rèn)對象內(nèi)部含有默認(rèn)值的方法
function a({x=1,y=2}={}){}

a()      // x:1,y:2
a({})    // x:1,y:2
a({x:2,z:5}) //x:2,y:2

這里先說明一下它的參數(shù)，后面讀起來會很順。

connectHOC: 一個重要組件，用于執(zhí)行已確定的邏輯，渲染最終組件，后面會詳細(xì)說。
mapStateToPropsFactories: 對 mapStateToProps 這個傳入的參數(shù)的類型選擇一個合適的方法。
mapDispatchToPropsFactories: 對 mapDispatchToProps 這個傳入的參數(shù)的類型選擇一個合適的方法。
mergePropsFactories: 對 mergeProps 這個傳入的參數(shù)的類型選擇一個合適的方法。 
selectorFactory: 以上3個只是簡單的返回另一個合適的處理方法，它則執(zhí)行這些處理方法，并且對結(jié)果定義了如何比較的邏輯。

可能有點繞，但react-redux就是這么一個個高階函數(shù)組成的，selectorFactory后面會詳細(xì)說。

首先我們再次確定這3個名字很長，實際很簡單的函數(shù)(源碼這里不放了)

mapStateToPropsFactories

mapDispatchToPropsFactories

mergePropsFactories

它們只是判斷了參數(shù)是否存在，是什么類型，并且返回一個合適的處理方法，它們并沒有任何處理邏輯。

舉個例子：

const MyComponent=connect((state)=>state.articles})

這里我只定義了mapStateToProps，并且是個function，那么mapStateToPropsFactories就會返回一個
處理function的方法。

我沒有定義mapDispatchToProps，那么mapDispatchToPropsFactories檢測不到參數(shù)，
則會提供一個默認(rèn)值dispatch => ({ dispatch })，返回一個處理非function(object)的方法。

那么處理邏輯是誰定義呢？

wrapMapToProps.js這個文件內(nèi)部做了以下事情：

定義了一個處理object的方法(簡單的返回即可，因為最終目的就是要object)。

定義了一個處理函數(shù)和高階函數(shù)(執(zhí)行2次)的方法，這個方法比上面的復(fù)雜在于它需要檢測參數(shù)是否訂閱了ownProps。

檢測方法很簡單，就是檢查參數(shù)的length（這里dependsOnOwnProps是上一次檢查的結(jié)果，如果存在則不需要再次檢查）

export function getDependsOnOwnProps(mapToProps) {
  return mapToProps.dependsOnOwnProps !== null &&
    mapToProps.dependsOnOwnProps !== undefined
    ? Boolean(mapToProps.dependsOnOwnProps)
    : mapToProps.length !== 1
}

回到connect，繼續(xù)往下看

export function createConnect({
  /* 上面所講的參數(shù) */
} = {}) {
  return function connect(
    mapStateToProps,
    mapDispatchToProps,
    mergeProps,
    {
      pure = true,
      areStatesEqual = strictEqual,
      areOwnPropsEqual = shallowEqual,
      areStatePropsEqual = shallowEqual,
      areMergedPropsEqual = shallowEqual,
      ...extraOptions
    } = {}
  ) {
  /* ... */
  }
}

已經(jīng)到了我們傳遞參數(shù)的地方，前3個參數(shù)意思就不解釋了，最后的參數(shù)options

areStatesEqual = strictEqual,           // ===比較
areOwnPropsEqual = shallowEqual,        // 淺比較
areStatePropsEqual = shallowEqual,      // 淺比較
areMergedPropsEqual = shallowEqual,     // 淺比較

它們用在selectorFactory這個比較數(shù)據(jù)結(jié)果的方法內(nèi)部。

繼續(xù)往下看

export function createConnect({
  /* 上面已講 */
} = {}) {
  return function connect(
    /* 上面已講 */
  ) {
    const initMapStateToProps = match(
      mapStateToProps,
      mapStateToPropsFactories,
      "mapStateToProps"
    )
    const initMapDispatchToProps = match(
      mapDispatchToProps,
      mapDispatchToPropsFactories,
      "mapDispatchToProps"
    )
    const initMergeProps = match(mergeProps, mergePropsFactories, "mergeProps")

這里定義了3個變量(函數(shù))，match的作用是什么？

以mapStateToProps舉例來說，

因為上面也說了，mapStateToPropsFactories里面有多個方法，需要找到一個適合mapStateToProps的，
match就是干這事了。

match方法內(nèi)部遍歷mapStateToPropsFactories所有的處理方法，任何一個方法能夠匹配參數(shù)mapStateToProps，便被match捕獲返回，
如果一個都找不到則報錯提示參數(shù)配置錯誤。

現(xiàn)在這3個變量定義明確了，都是對應(yīng)的參數(shù)的合適的處理方法。

至此，我們已經(jīng)完成了第二階段，

做個小總結(jié)，第二階段做了哪些事：

connect接收了對參數(shù)處理方案(3個...Factories)。

connect接收了參數(shù)的結(jié)果比較方案(selectFactory)

connect接收了參數(shù)(mapStateToProps,mapDispatchToProps,mergeProps,options)。

定義了比較方案(4個are...Equal，其實就是全等比較和淺比較)。

前2個階段都是定義階段，接下來需要我們傳入自定義組件，也就是最后一個階段

connect(...)(Component)

接著看connect源碼

export function createConnect({
  /* 上面已講 */
} = {}) {
  return function connect(
    /* 上面已講 */
  ) {
    /* 上面已講 */
    return connectHOC(selectorFactory, {
      // 方法名稱，用在錯誤提示信息
      methodName: "connect",
      // 最終渲染的組件名稱
      getDisplayName: name => `Connect(${name})`,
      shouldHandleStateChanges: Boolean(mapStateToProps),
      // 以下是傳遞給 selectFactory
      initMapStateToProps,
      initMapDispatchToProps,
      initMergeProps,
      pure,
      areStatesEqual,
      areOwnPropsEqual,
      areStatePropsEqual,
      areMergedPropsEqual,

      // any extra options args can override defaults of connect or connectAdvanced
      ...extraOptions
    })
  }
}

這里執(zhí)行了connectHOC()，傳遞了上面已經(jīng)講過的參數(shù)，而connectHOC = connectAdvanced

因此我們進(jìn)入最后一個對外API，connectAdvanced

connectAdvanced函數(shù)，之前也提過，就是一個執(zhí)行、組件渲染和組件更新的地方。

它里面沒有什么新概念，都是將我們上面講到的參數(shù)進(jìn)行調(diào)用，最后根據(jù)結(jié)果進(jìn)行渲染新組件。

還是從源碼開始

export default function connectAdvanced(
  selectorFactory,
  {
    // 執(zhí)行后作用于connect這個HOC組件名稱
    getDisplayName = name => `ConnectAdvanced(${name})`,
    // 用于錯誤提示
    methodName = "connectAdvanced",
    // 有REMOVED標(biāo)志，這里不關(guān)注
    renderCountProp = undefined,
    // 確定connect這個HOC是否訂閱state變動，好像已經(jīng)沒有用到了
    shouldHandleStateChanges = true,
    // 有REMOVED標(biāo)志，這里不關(guān)注
    storeKey = "store",
    // 有REMOVED標(biāo)志，這里不關(guān)注
    withRef = false,
    // 是否通過 forwardRef 暴露出傳入的Component的DOM
    forwardRef = false,
    // React的createContext
    context = ReactReduxContext,

    // 其余的(比較方法，參數(shù)處理方法等)將會傳遞給上面的 selectFactory
    ...connectOptions
  } = {}
) {
  /* ... */
}

參數(shù)也沒什么特別的，有一個forwardRef作用就是能獲取到我們傳入的Component的DOM。
這里也不深入。

接著看

export default function connectAdvanced(
  /* 上面已講 */
) {
  /* ...對參數(shù)的一些驗證和提示哪些參數(shù)已經(jīng)作廢... */
  
  // 定義Context
  const Context = context

  return function wrapWithConnect(WrappedComponent) {
    /* ...檢查 WrappedComponent 是否符合要求... */
   
    /* ...獲取傳入的WrappedComponent的名稱... */
   
    /* ...通過WrappedComponent的名稱計算出當(dāng)前HOC的名稱... */

    /* ...獲取一些上面的參數(shù)(沒有新的參數(shù),都是之前見過的)... */

    // Component就是React.Component
    let OuterBaseComponent = Component
    let FinalWrappedComponent = WrappedComponent

    // 是否純組件
    if (pure) {
      OuterBaseComponent = PureComponent
    }

    /* 定義 makeDerivedPropsSelector 方法，作用后面講 */

    /* 定義 makeChildElementSelector 方法，作用后面講 */

    /* 定義 Connect 組件，作用后面講 */

    Connect.WrappedComponent = WrappedComponent
    Connect.displayName = displayName

    /* ...如果是forWardRef 為true的情況，此處不深入... */
    
    // 靜態(tài)方法轉(zhuǎn)換
    return hoistStatics(Connect, WrappedComponent)
  }
}

這一段特別長，因此我將不太重要的直接用注釋說明了它們在做什么，具體代碼就不放了(不重要)。

并且定義了3個新東西，makeDerivedPropsSelector，makeChildElementSelector,Connect。

先看最后一句hoistStatics就是hoist-non-react-statics，它的作用是將組件WrappedComponent的所有非React
靜態(tài)方法傳遞到Connect內(nèi)部。

那么最終它還是返回了一個Connect組件。

這個組件已經(jīng)是我們寫了完整connect(...)(Component)的返回值了，所以能確定，只要調(diào)用，就能渲染出一個新的組件出來。

因此它的功能就是確定是否重復(fù)更新組件和確定到底更新什么？

看一個組件，從constructor看起

class Connect extends OuterBaseComponent {
  constructor(props) {
    super(props)
   
    /* ...提示一些無用的參數(shù)...*/
    
    this.selectDerivedProps = makeDerivedPropsSelector()
    this.selectChildElement = makeChildElementSelector()
    this.renderWrappedComponent = this.renderWrappedComponent.bind(this)
  }
  /* ... */
}

綁定了一個方法，看名字是render的意思，先不管它。

執(zhí)行了2個函數(shù)。

Connect組件還沒完，這里先放著，我們先看makeDerivedPropsSelector和makeChildElementSelector

function makeDerivedPropsSelector() {
  // 閉包儲存上一次的執(zhí)行結(jié)果
  let lastProps
  let lastState
  let lastDerivedProps
  let lastStore
  let sourceSelector

  return function selectDerivedProps(state, props, store) {
    // props和state都和之前相等 直接返回上一次的結(jié)果
    if (pure && lastProps === props && lastState === state) {
      return lastDerivedProps
    }

    // 當(dāng)前store和lastStore不等，更新lastStore
    if (store !== lastStore) {
      lastStore = store
      
      // 終于調(diào)用 selectorFactory 了
      sourceSelector = selectorFactory(
        store.dispatch,
        selectorFactoryOptions
      )
    }

    // 更新數(shù)據(jù)
    lastProps = props
    lastState = state

    // 返回的就是最終的包含所有相應(yīng)的 state 和 props 的結(jié)果
    const nextProps = sourceSelector(state, props)

    // 最終的比較
    if (lastDerivedProps === nextProps) {
      return lastDerivedProps
    }
    lastDerivedProps = nextProps
    return lastDerivedProps
  }
}

大概的說，makeDerivedPropsSelector的執(zhí)行，先判斷了當(dāng)前傳入的props(組件的props)和state(redux傳入的state)
跟以前的是否全等，如果全等就不需要更新了；

如果不等，則調(diào)用了高階函數(shù)selectFactory，并且獲得最終數(shù)據(jù)，最后再判斷最終數(shù)據(jù)和之前的最終數(shù)據(jù)是否全等。

為什么第一次判斷了，還要判斷第二次，而且都是===判斷？

因為第一次獲取的state是redux傳入的，是整個APP的所有數(shù)據(jù)，它們不等說明有組件更新了，但不確定是否是當(dāng)前組件；

第二次比較的是當(dāng)前組件的最新數(shù)據(jù)和以前數(shù)據(jù)對比。

現(xiàn)在，我們知道selectFactory的作用是獲取當(dāng)前組件的的最新數(shù)據(jù)，深入源碼看看。

export default function finalPropsSelectorFactory(
  // redux store的store.dispatch
  dispatch,
  // 3種已經(jīng)確定了的處理方法
  { initMapStateToProps, initMapDispatchToProps, initMergeProps, ...options }
) {
  // 返回一個針對用戶傳入的類型的解析函數(shù)
  // 例如 mapStateToProps 如果是function，那么就返回proxy，proxy可以判斷是否需要ownProps，并且對高階函數(shù)的 mapStateToProps 進(jìn)行2次處理，
  // 最終確保返回一個plainObject，否則報錯
  const mapStateToProps = initMapStateToProps(dispatch, options)
  const mapDispatchToProps = initMapDispatchToProps(dispatch, options)
  const mergeProps = initMergeProps(dispatch, options)

  if (process.env.NODE_ENV !== "production") {
    verifySubselectors(
      mapStateToProps,
      mapDispatchToProps,
      mergeProps,
      options.displayName
    )
  }

  const selectorFactory = options.pure
    ? pureFinalPropsSelectorFactory
    : impureFinalPropsSelectorFactory

  // 默認(rèn)pure問題true，因此執(zhí)行 pureFinalPropsSelectorFactory(...)
  return selectorFactory(
    mapStateToProps,
    mapDispatchToProps,
    mergeProps,
    dispatch,
    options
  )
}

參數(shù)就不說了，看注釋。

以下3個，到底返回了什么，源碼在wrapMapToProps.js，上面也說過這個文件內(nèi)部做了什么事情。

const mapStateToProps = initMapStateToProps(dispatch, options)
const mapDispatchToProps = initMapDispatchToProps(dispatch, options)
const mergeProps = initMergeProps(dispatch, options)

這3個調(diào)用返回的一個函數(shù)，名字叫proxy，這個proxy一旦調(diào)用，
就能返回經(jīng)過mapStateToProps, mapDispatchToProps, mergeProps這3個參數(shù)處理過后的數(shù)據(jù)(plainObject)。

接下來：

const selectorFactory = options.pure
    ? pureFinalPropsSelectorFactory
    : impureFinalPropsSelectorFactory

  // 默認(rèn)pure問題true，因此執(zhí)行 pureFinalPropsSelectorFactory(...)
  return selectorFactory(
    mapStateToProps,
    mapDispatchToProps,
    mergeProps,
    dispatch,
    options
  )

返回了selectorFactory的調(diào)用值，也就是pureFinalPropsSelectorFactory(pure默認(rèn)為true)。

看pureFinalPropsSelectorFactory，它的代碼不少，但邏輯很明了，大方向就是對比數(shù)據(jù)。

這里關(guān)鍵的如何比較不列代碼，只用注釋講明白它的邏輯。

export function pureFinalPropsSelectorFactory(
  // 接受3個proxy方法
  mapStateToProps,
  mapDispatchToProps,
  mergeProps,
  dispatch,
  // 接受3個比較方法
  { areStatesEqual, areOwnPropsEqual, areStatePropsEqual }
) {
  
  /* ...定義變量保存之前的數(shù)據(jù)(閉包)... */

  function handleFirstCall(firstState, firstOwnProps) {
    /* ...定義第一次執(zhí)行數(shù)據(jù)比較的方法，也就是簡單的賦值給上面定義的閉包變量... */
  }

  function handleNewPropsAndNewState() {
    /* 當(dāng)state和props都有變動時的處理方法 */
  }

  function handleNewProps() {
    /* 當(dāng)state無變動，props有變動時的處理方法 */
  }

  function handleNewState() {
    /* 當(dāng)state有變動，props無變動時的處理方法 */
  }

  // 后續(xù)數(shù)據(jù)比較的方法
  function handleSubsequentCalls(nextState, nextOwnProps) {
    // 淺比較
    const propsChanged = !areOwnPropsEqual(nextOwnProps, ownProps)
    // 全等比較
    const stateChanged = !areStatesEqual(nextState, state)
    // 更新數(shù)據(jù)
    state = nextState
    ownProps = nextOwnProps
    // 當(dāng)發(fā)生不相等的3種情況(關(guān)鍵)
    if (propsChanged && stateChanged) return handleNewPropsAndNewState()
    if (propsChanged) return handleNewProps()
    if (stateChanged) return handleNewState()
    // 比較都相等，直接返回舊值
    return mergedProps
  }
  return function pureFinalPropsSelector(nextState, nextOwnProps) {
    return hasRunAtLeastOnce
      ? handleSubsequentCalls(nextState, nextOwnProps)
      : handleFirstCall(nextState, nextOwnProps)
  }
}

上面的閉包變量儲存了上一次的數(shù)據(jù)，關(guān)鍵點就是當(dāng)和這一次的數(shù)據(jù)比較后，如果處理更新。

react-redux將它分為3種情況

state和props都相等。

state相等，props不等。

state不等，props相等。

第一種：state和props都相等

mapStateToProps(proxy)：

不管是否訂閱ownProps，執(zhí)行mapStateToProps， 因為state有變動。

mapDispatchToProps(proxy)：

只有訂閱了ownProps，才會執(zhí)行mapDispatchToProps，因為state變動與mapDispatchToProps無影響。

mergedProps(proxy)：

必定執(zhí)行，將所有結(jié)果合并。

第二種：state相等，props不等

mapStateToProps(proxy)：

只有訂閱了ownProps，才會執(zhí)行mapStateToProps， 因為state無變動。

mapDispatchToProps(proxy)：

只有訂閱了ownProps，才會執(zhí)行mapDispatchToProps，因為state變動與mapDispatchToProps無影響。

mergedProps(proxy)：

必定執(zhí)行，將所有結(jié)果合并。

第三種：state不等，props相等

mapStateToProps(proxy)：

不管是否訂閱ownProps，執(zhí)行mapStateToProps， 因為state有變動。

注意，這里結(jié)果需要淺比較判斷

因為如果沒有淺比較檢查，而兩者剛好淺比較相等，
那么最后也會認(rèn)為返回一個新的props，也就是相當(dāng)于重復(fù)更新了。

之所以第一個state和props都有變動的不需要淺比較檢查，
是因為如果props變了，則必須要更新組件。

mapDispatchToProps(proxy)：

不會執(zhí)行，因為它只關(guān)注props。

mergedProps(proxy)：

只有上面淺比較不等，才會執(zhí)行。

makeDerivedPropsSelector的總結(jié)：

通過閉包管理數(shù)據(jù)，并且通過淺比較和全等比較判斷是否需要更新組件數(shù)據(jù)。

makeChildElementSelector也是一個高階函數(shù)，儲存了之前的數(shù)據(jù)和組件，并且判斷與當(dāng)前的判斷。

這里是最終渲染組件的地方，因為需要判斷一下剛才最終給出的數(shù)據(jù)是否需要去更新組件。

2個邏輯：

數(shù)據(jù)與之前不等(===)，更新組件。

forWardRef屬性值與之前不等，更新組件。

否則，返回舊組件(不更新)。

繼續(xù)回到Connect組件。

之后就是render了

render() {
  // React的createContext
  const ContextToUse = this.props.context || Context

  return (
    
      {this.renderWrappedComponent}
    
  )
}

Context.Consumer內(nèi)部必須是一個函數(shù)，這個函數(shù)的參數(shù)就是Context.Provider的value，也就是redux的store。

最后一個函數(shù)：renderWrappedComponent

renderWrappedComponent(value) {
  /* ...驗證參數(shù)有效性... */
  
  // 這里 storeState=store.getState()
  const { storeState, store } = value

  // 傳入自定義組件的props
  let wrapperProps = this.props
  
  let forwardedRef
  if (forwardRef) {
    wrapperProps = this.props.wrapperProps
    forwardedRef = this.props.forwardedRef
  }

  // 上面已經(jīng)講了，返回最終數(shù)據(jù)
  let derivedProps = this.selectDerivedProps(
    storeState,
    wrapperProps,
    store
  )

  // 返回最終渲染的自定義組件
  return this.selectChildElement(derivedProps, forwardedRef)
}

總算結(jié)束了，可能有點混亂，做個總結(jié)吧。

我把react-redux的執(zhí)行流程分為3個階段，分別對應(yīng)我們的代碼編寫(搭配導(dǎo)圖閱讀)

一張導(dǎo)圖：

第一階段：

對應(yīng)的用戶代碼：

執(zhí)行內(nèi)容有：

定義了Provider組件，這個組件內(nèi)部訂閱了redux的store，保證當(dāng)store發(fā)生變動，會立刻執(zhí)行更新。

第二階段：

對應(yīng)的用戶代碼：

connect(mapStateToProps,mapDispatchToProps,mergeProps,options)

執(zhí)行內(nèi)容有：

connect接收了參數(shù)(mapStateToProps,mapDispatchToProps,mergeProps,options)。

connect接收了對參數(shù)如何處理方案(3個...Factories)。

connect接收了參數(shù)的結(jié)果比較方案(selectFactory)

定義了比較方案(4個are...Equal，其實就是全等比較和淺比較)。

第三階段：

對應(yīng)的用戶代碼：

let newComponent=connect(...)(Component)

執(zhí)行內(nèi)容有：

接受自定義組件(Component)。

創(chuàng)建一個Connect組件。

將Component的非React靜態(tài)方法轉(zhuǎn)移到Connect。

獲取Provider傳入的數(shù)據(jù)(redux的整個數(shù)據(jù))，利用閉包保存數(shù)據(jù)，用于和未來數(shù)據(jù)做比較。

當(dāng)比較(===)有變動，執(zhí)行上一階段傳入的參數(shù)，獲取當(dāng)前組件真正的數(shù)據(jù)。

利用閉包保存當(dāng)前組件真正的數(shù)據(jù)，用于和未來作比較。

通過全等和淺比較，處理state變動和props變動的邏輯，判斷返回新數(shù)據(jù)還是舊數(shù)據(jù)。

利用閉包保存渲染的組件，通過上面返回的最終數(shù)據(jù)，判斷需要返回新組件還是就組件。

邏輯理順了，還是很好理解的。

其中第三階段就是對外APIconnectAdvanced的執(zhí)行內(nèi)容。

此處查看更多前端源碼閱讀內(nèi)容。

或許哪一天，我們需要設(shè)計一個專用的數(shù)據(jù)管理系統(tǒng)，那么就利用好connectAdvanced，
我們要做的就是編寫一個自定義第二階段的邏輯體系。

感謝閱讀！