react-router 源码浅析

用 react-router 也用了比较久了,对他的内部工作方式却只是了解皮毛,而且大部分还是通过别人的博客。最近两周打算自己探究一下他的实现。
注意!因为我只使用过 v3 版本的 react-router,因为对他的使用方式比较熟悉,所以这次解析也是基于这个版本。

文章目录:

  • react-router 工作模式简化流程
  • 内部具体实现 ( 最后来个图片综上)
  • Link 组件的实现方式 以及 *History.push 的实现方式
  • 为什么要这样实现?有什么别的方式?做个比较?

react-router 工作模式简化流程

聊到这个话题就离不开前端路由。关于前端路由的一些演变过程和现有的方式可以看这篇文章。前端路由的重点就是不刷新页面,现有的解决方案有 hashChange 和 popState 两种。
React 提供API也是围绕这两种方式。 共同点都是发布订阅的模式,让浏览器事件触发的时候自己添加的 listener 被调用。Router 组件包裹着 Route 组件,Route 组件负责描述每条路由的展示组件和匹配的路径。这样 Router 组件实际上会格式化出一个映射的路由表
然而这是在页面路由更新的时候,最开始进入页面的时候怎么办呢?其实刚进入页面的时候也会进行一次匹配,详细分析见下一部分。

内部具体实现

首先解答上面的遗留问题,刚进入页面的状态如何带入?这个问题我们可以和 "Router 组件是在什么时候添加的事件监听"放在一起解答。

  componentWillMount() {//来源:modules/Router.js
    this.transitionManager = this.createTransitionManager()
    this.router = this.createRouterObject(this.state)

    this._unlisten = this.transitionManager.listen((error, state) => {
      if (error) {
        this.handleError(error)
      } else {
        // Keep the identity of this.router because of a caveat in ContextUtils:
        // they only work if the object identity is preserved.
        assignRouterState(this.router, state)
        this.setState(state, this.props.onUpdate)
      }
    })
  },

Router 组件在 willMount 生命周期添加了 listener,而添加 listener 本身就会触发一次匹配路由展示的过程。匹配的过程有 match 方法,用于各种嵌套路由的匹配。
但是注意,如果使用的是 browserHistory,这种路由方式一般是/a/b 这种方式,可能需要后端同学的配合。

封装 history ——transitionManager

在上面的代码中,我们会注意到添加监听器的 listen方法来自于 transitionManager 这个生成之后被赋值到 this.router 实例的属性。实际上 react-router 的事件监听过程是用 transitionManager 套了 history 这个库,抹平各种前端路由 方式的调用差异。history库本身暴露了一些API 比如监听、取消监听、跳转等一系列方法。有基于咱们刚才提到的 hash 和 state 两种方式。我们传给 Router 组件 history 属性的值其实就是他的实例。(拿hashHistory 举栗,下面的文件是 reate-router export 的 hashHistory 的来源,也就是我们用的 hashHistory 的来源)。

//来源:modules/hashHistory.js
import createHashHistory from 'history/lib/createHashHistory'
import createRouterHistory from './createRouterHistory'
export default createRouterHistory(createHashHistory)

而 transitionManager 做的事情是针对当前的 router 实例和开发者指定的 history 对象,对 history 库给的 API 做一次二次封装,加上修改路由状态等等操作。然后开发者拿着 transitionManager 封装之后暴露出的 listen 等方法操作路由。

  createTransitionManager() {//来源:modules/Router.js
    const { matchContext } = this.props
    if (matchContext) {
      return matchContext.transitionManager
    }

    const { history } = this.props
    const { routes, children } = this.props

    invariant(
      history.getCurrentLocation,
      'You have provided a history object created with history v4.x or v2.x ' +
        'and earlier. This version of React Router is only compatible with v3 ' +
        'history objects. Please change to history v3.x.'
    )

    return createTransitionManager(//注意这个createTransitionManager才是
      history,
      createRoutes(routes || children)
    )
  },
渲染部分

渲染过程不是放在 Route 组件中负责渲染,而是把状态都放在 Router 中保存,详细可见第一部分的代码添加 listener 的部分。

     assignRouterState(this.router, state)
     this.setState(state, this.props.onUpdate)

而 Router 组件的 render 是这样写的:

    const { location, routes, params, components } = this.state
    const { createElement, render, ...props } = this.props

    return render({
      ...props,
      router: this.router,
      location,
      routes,
      params,
      components,
      createElement
    })

而 props 的值是当前 Router 组件的状态,他现在要展示的组件,对应的地址,当前跳转携带的参数 params 等等。下面是调用 render 的部分。

  return 

RouterContext 包装组件的主要作用就是把 props参数中存有当前路由状态的对象router存到全局。类似于 Redux 的 Provider 组件。

Link 组件的实现方式

这里小伙伴们可以猜测一下,Link是怎么做的呢?我们知道 Link最后渲染完是个 a 标签,我们通常会给 Link 组件几个参数,最常用的是跳转的路由地址和携带的参数。通过上面的讲解不难猜出,Link 在点击的时候应该是调用了一个跳转的操作(八成也是 history 库里给的),然后禁止掉默认跳转就行了。
事实也是如此,history 暴露了一个 push方法,来 push 进浏览器的历史访问栈中。
这里再提一句另外一种用法:*history.push() 的方式。这种其实就相当于直接点击了 a 标签一样的道理,只不过用 js 的方式实现了。

为什么要这样实现?有什么别的方式?做个比较?

我们可不可以尝试把展示交给 route 组件管理?router 只控制激活当前的 route?但是这样就不能支持通过 props 传给 router 路由配置的方式使用了,这是其一;其二,这样其实 route 其实负责了组件的渲染工作,而不是把所有的状态和路由信息全部放在 router 中管理了,不方便集中维护和扩展。
不知道小伙伴们还有别的看法吗?

(本来想写个浅析的……噼里啪啦写了一大堆……还捎带点语无伦次……)
(但是虽然说了一堆……不过确实挺浅的……各位有兴趣可以尝试自己扒一下源码。建议 react-router 和 history 库一起 debug,更有助于我们融会贯通)
( 各位见笑了)

你可能感兴趣的:(react-router 源码浅析)