Two implementations of front-end routing from vue-router

As the business functions of front-end applications become more and more complex and users' requirements for user experience become higher and higher, single-page applications (SPA) have become the mainstream form of front-end applications. One of the most notable features of large single-page applications is the use of a front-end routing system that updates page views by changing the URL without re-requesting the page.

"Updating the view without re-requesting the page" is one of the core principles of front-end routing. Currently, there are two main ways to implement this function in the browser environment:

• Exploiting the hash (“#”) in the URL
• New methods in HTML5 using the History interface
  

vue-router is a routing plug-in for the Vue.js framework. Let's start with its source code, read the code and the principles, and learn from the shallower to the deeper how vue-router implements front-end routing through these two methods.

Mode Parameters

In vue-router, the mode parameter is used to control the routing implementation mode:

const router = new VueRouter({
  mode: 'history',
  routes: [...]
})

When creating an instance object of VueRouter, mode is passed in as a constructor parameter. Reading the source code with questions in mind, we can start with the definition of the VueRouter class. Generally, the classes exposed by the plug-in are defined in the index.js file in the root directory of the source code src. Open the file and you can see the definition of the VueRouter class. The excerpts related to the mode parameter are as follows:

export default class VueRouter {
  
  mode: string; // The string parameter passed in indicates the history categoryhistory: HashHistory | HTML5History | AbstractHistory; // The object property that actually works must be an enumeration of the above three classesfallback: boolean; // If the browser does not support it, the 'history' mode needs to be rolled back to the 'hash' modeconstructor (options: RouterOptions = {}) {
    
    let mode = options.mode || 'hash' // Defaults to 'hash' mode this.fallback = mode === 'history' && !supportsPushState // Use supportsPushState to determine whether the browser supports 'history' mode if (this.fallback) {
      mode = 'hash'
    }
    if (!inBrowser) {
      mode = 'abstract' // If not running in a browser environment, force it to be in 'abstract' mode}
    this.mode = mode

    // Determine the actual class of history based on mode and instantiate switch (mode) {
      case 'history':
        this.history = new HTML5History(this, options.base)
        break
      case 'hash':
        this.history = new HashHistory(this, options.base, this.fallback)
        break
      case 'abstract':
        this.history = new AbstractHistory(this, options.base)
        break
      default:
        if (process.env.NODE_ENV !== 'production') {
          assert(false, `invalid mode: ${mode}`)
        }
    }
  }

  init (app: any /* Vue component instance */) {
    
    const history = this.history

    // Perform corresponding initialization operations and monitoring according to the history category if (history instanceof HTML5History) {
      history.transitionTo(history.getCurrentLocation())
    } else if (history instanceof HashHistory) {
      const setupHashListener = () => {
        history.setupListeners()
      }
      history.transitionTo(
        history.getCurrentLocation(),
        setupHashListener,
        setupHashListener
      )
    }

    history.listen(route => {
      this.apps.forEach((app) => {
        app._route = route
      })
    })
  }

  // The following method exposed by the VueRouter class actually calls the method of the specific history object push (location: RawLocation, onComplete?: Function, onAbort?: Function) {
    this.history.push(location, onComplete, onAbort)
  }

  replace (location: RawLocation, onComplete?: Function, onAbort?: Function) {
    this.history.replace(location, onComplete, onAbort)
  }
}

It can be seen that:

The string attribute mode passed as a parameter is just a marker to indicate the implementation class of the object attribute history that actually works. The corresponding relationship between the two is as follows:

Before initializing the corresponding history, some checks will be done on the mode: if the browser does not support the HTML5History method (judged by the supportsPushState variable), the mode is forced to be set to 'hash'; if it is not running in a browser environment, the mode is forced to be set to 'abstract'

The onReady(), push() and other methods in the VueRouter class are just a proxy. They actually call the corresponding methods of the specific history object. When initialized in the init() method, different operations are performed according to the specific category of the history object.

The two methods in the browser environment are implemented in the HTML5History and HashHistory classes respectively. They are all defined in the src/history folder and inherit from the History class defined in the base.js file in the same directory. History defines common and basic methods, which may be confusing to read directly. Let's start with the familiar push() and replace() methods in the HTML5History and HashHistory classes.

HashHistory

Let's review the principle before looking at the source code:

The hash ("#") symbol is originally added to the URL to indicate the location of the web page:

www.example.com/index.html#…

The # symbol itself and the characters following it are called hash, which can be read through the window.location.hash property. It has the following features:

• Although the hash appears in the URL, it is not included in the HTTP request. It is used to guide browser actions and is completely useless to the server. Therefore, changing the hash will not reload the page.
• You can add listener events for hash changes:

window.addEventListener("hashchange", funcRef, false)

Every time the hash (window.location.hash) is changed, a record is added to the browser's access history.

By using the above characteristics of hash, you can implement the function of "updating the view but not re-requesting the page" in the front-end routing.

HashHistory.push()

Let's look at the push() method in HashHistory:

push (location: RawLocation, onComplete?: Function, onAbort?: Function) {
  this.transitionTo(location, route => {
    pushHash(route.fullPath)
    onComplete && onComplete(route)
  }, onAbort)
}

function pushHash (path) {
  window.location.hash = path
}

The transitionTo() method is defined in the parent class to handle the basic logic of route changes. The push() method is mainly used to directly assign the hash of the window:

window.location.hash = route.fullPath

Changes to the hash are automatically added to the browser's access history.

So how is the view updated? Let's look at the transitionTo() method in the parent class History:

transitionTo (location: RawLocation, onComplete?: Function, onAbort?: Function) {
  const route = this.router.match(location, this.current)
  this.confirmTransition(route, () => {
    this.updateRoute(route)
    ...
  })
}

updateRoute (route: Route) {
  
  this.cb && this.cb(route)
  
}

listen (cb: Function) {
  this.cb = cb
}

As you can see, when the route changes, the this.cb method in History is called, and the this.cb method is set through History.listen(cb). Going back to the VueRouter class definition, we found that it was set in the init() method:

init (app: any /* Vue component instance */) {
    
  this.apps.push(app)

  history.listen(route => {
    this.apps.forEach((app) => {
      app._route = route
    })
  })
}

According to the comments, app is a Vue component instance, but we know that Vue, as a progressive front-end framework, should not have a built-in route attribute _route in its component definition. If the component needs this attribute, it should be mixed into the Vue object in the place where the plug-in is loaded, that is, in the install() method of VueRouter. Check the install.js source code, there is the following paragraph:

export function install (Vue) {
  
  Vue.mixin({
    beforeCreate () {
      if (isDef(this.$options.router)) {
        this._router = this.$options.router
        this._router.init(this)
        Vue.util.defineReactive(this, '_route', this._router.history.current)
      }
      registerInstance(this, this)
    },
  })
}

Through the Vue.mixin() method, a mixin is registered globally, affecting every Vue instance created after registration. The mixin defines a responsive _route attribute through Vue.util.defineReactive() in the beforeCreate hook. The so-called responsive property means that when the _route value changes, the render() method of the Vue instance will be automatically called to update the view.

To summarize, the process from setting route changes to view updates is as follows:

$router.push() --> HashHistory.push() --> History.transitionTo() --> History.updateRoute() --> {app._route = route} --> vm.render()

HashHistory.replace()

The replace() method differs from the push() method in that it does not add the new route to the top of the browser's access history stack, but replaces the current route:

replace (location: RawLocation, onComplete?: Function, onAbort?: Function) {
  this.transitionTo(location, route => {
    replaceHash(route.fullPath)
    onComplete && onComplete(route)
  }, onAbort)
}
  
function replaceHash (path) {
  const i = window.location.href.indexOf('#')
  window.location.replace(
    window.location.href.slice(0, i >= 0 ? i : 0) + '#' + path
  )
}

It can be seen that its implementation structure is basically similar to that of push(). The difference is that it does not directly assign a value to window.location.hash, but calls the window.location.replace method to replace the route.

Listen to the address bar

The VueRouter.push() and VueRouter.replace() discussed above can be called directly in the logic code of the vue component. In addition, in the browser, users can also directly enter changes to the route in the browser address bar. Therefore, VueRouter also needs to be able to monitor changes in the route in the browser address bar and have the same response behavior as calling through code. In HashHistory, this function is implemented through setupListeners:

setupListeners() {
  window.addEventListener('hashchange', () => {
    if (!ensureSlash()) {
      return
    }
    this.transitionTo(getHash(), route => {
      replaceHash(route.fullPath)
    })
  })
}

This method sets the browser event hashchange as the listener, and the function called is replaceHash, that is, directly entering the route in the browser address bar is equivalent to calling the replace() method in the code.

HTML5History

History interface is the interface provided by the browser history stack. Through methods such as back(), forward(), go(), etc., we can read the information of the browser history stack and perform various jump operations.

Starting from HTML5, History interface provides two new methods: pushState() and replaceState(), which allow us to modify the browser history stack:

window.history.pushState(stateObject, title, URL)
window.history.replaceState(stateObject, title, URL)

• stateObject: When the browser jumps to a new state, a popState event will be triggered, which will carry a copy of this stateObject parameter
• title: the title of the record being added
• URL: URL of the record being added
  

These two methods have a common feature: when they are called to modify the browser history stack, although the current URL has changed, the browser will not immediately send a request to the URL (the browser won't attempt to load this URL after a call to pushState()), which provides the basis for the single-page application front-end routing to "update the view but not re-request the page".

Let's look at the source code in vue-router:

push (location: RawLocation, onComplete?: Function, onAbort?: Function) {
  const { current: fromRoute } = this
  this.transitionTo(location, route => {
    pushState(cleanPath(this.base + route.fullPath))
    handleScroll(this.router, route, fromRoute, false)
    onComplete && onComplete(route)
  }, onAbort)
}

replace (location: RawLocation, onComplete?: Function, onAbort?: Function) {
  const { current: fromRoute } = this
  this.transitionTo(location, route => {
    replaceState(cleanPath(this.base + route.fullPath))
    handleScroll(this.router, route, fromRoute, false)
    onComplete && onComplete(route)
  }, onAbort)
}

// src/util/push-state.js
export function pushState (url?: string, replace?: boolean) {
  saveScrollPosition()
  // try...catch the pushState call to get around Safari
  // DOM Exception 18 where it limits to 100 pushState calls
  const history = window.history
  try {
    if (replace) {
      history.replaceState({ key: _key }, '', url)
    } else {
      _key = genKey()
      history.pushState({ key: _key }, '', url)
    }
  } catch (e) {
    window.location[replace ? 'replace' : 'assign'](url)
  }
}

export function replaceState (url?: string) {
  pushState(url, true)
}

The code structure and logic of updating views are basically similar to the hash mode, except that the direct assignment of window.location.hash to window.location.replace() is changed to calling history.pushState() and history.replaceState() methods.

Adding a listener for modifying the URL in the browser address bar in HTML5History is executed directly in the constructor:

constructor (router: Router, base: ?string) {
  
  window.addEventListener('popstate', e => {
    const current = this.current
    this.transitionTo(getLocation(this.base), route => {
      if (expectScroll) {
        handleScroll(router, route, current, true)
      }
    })
  })
}

Of course, HTML5History uses new features of HTML5, which requires support from a specific browser version. As we have already seen, whether the browser supports it is checked through the variable supportsPushState:

// src/util/push-state.js
export const supportsPushState = inBrowser && (function () {
  const ua = window.navigator.userAgent

  if (
    (ua.indexOf('Android 2.') !== -1 || ua.indexOf('Android 4.0') !== -1) &&
    ua.indexOf('Mobile Safari') !== -1 &&
    ua.indexOf('Chrome') === -1 &&
    ua.indexOf('Windows Phone') === -1
  ) {
    return false
  }

  return window.history && 'pushState' in window.history
})()

The above is an introduction to the source code of hash mode and history mode. Both modes are implemented through the browser interface. In addition, vue-router also prepares an abstract mode for non-browser environments. The principle is to use an array stack to simulate the function of the browser history stack. Of course, the above are just some core logics. To ensure the robustness of the system, there are a lot of auxiliary logics in the source code, which are also worth learning. In addition, there are important parts such as route matching and router-view view components in vue-router

Comparison of the two modes

In general demand scenarios, hash mode and history mode are similar, but almost all articles recommend using history mode. The reason is: the "#" symbol is too ugly...0_0 "

If we don't want ugly hashes, we can use the history mode of the router - official documentation

Of course, as rigorous people, we should definitely not judge the quality of technology based on appearance. According to MDN, calling history.pushState() has the following advantages over directly modifying the hash:

• The new URL set by pushState can be any URL with the same origin as the current URL; hash can only modify the part after #, so it can only set the URL of the same document as the current one
• The new URL set by pushState can be exactly the same as the current URL, which will also add the record to the stack; the new value set by hash must be different from the original value to trigger the record to be added to the stack
• pushState can add any type of data to the record through stateObject; while hash can only add short strings
• pushState can additionally set the title attribute for subsequent use
  

A problem with history mode

We know that for single-page applications, the ideal usage scenario is to load index.html only when entering the application, and subsequent network operations are completed through Ajax, without re-requesting the page according to the URL. However, it is inevitable to encounter special situations, such as the user directly enters the address bar and presses Enter, the browser restarts and reloads the application, etc.

The hash mode only changes the content of the hash part, and the hash part will not be included in the HTTP request:

http://oursite.com/#/user/id // If you re-request, only http://oursite.com/ will be sent

Therefore, there will be no problem in hash mode when requesting pages based on URLs.

The history mode will modify the URL to be the same as the URL of the normal request backend.

http://oursite.com/user/id

In this case, resend the request to the backend. If the backend is not configured with the corresponding /user/id routing processing, a 404 error will be returned. The officially recommended solution is to add a candidate resource on the server side to cover all situations: if the URL does not match any static resource, the same index.html page should be returned, which is the page your app depends on. Also, by doing this, the server will no longer return a 404 error page, because the index.html file will be returned for all paths. To avoid this, cover all routing situations in the Vue application and then give a 404 page. Alternatively, if you use Node.js as the backend, you can use the server-side routing to match the URL and return 404 when no route is matched, thus implementing fallback.

Directly load application files

Tip: built files are meant to be served over an HTTP server.

Opening index.html over file:// won't work.

After the Vue project is packaged through vue-cli's webpack, the command line will have the following prompt. Normally, whether in development or online, front-end projects are accessed through the server, and there is no "Opening index.html over file://". However, programmers all know that requirements and scenarios are always strange. There is nothing that product managers cannot think of, only what you can't think of.

The original intention of writing this article was to encounter such a problem: I needed to quickly develop a mobile display project, and decided to use WebView to load the Vue single-page application, but there was no backend server provided, so all resources needed to be loaded from the local file system:

//AndroidAppWrapper
public class MainActivity extends AppCompatActivity {

    private WebView webView;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        webView = new WebView(this);
        webView.getSettings().setJavaScriptEnabled(true);
        webView.loadUrl("file:///android_asset/index.html");
        setContentView(webView);
    }

    @Override
    public boolean onKeyDown(int keyCode, KeyEvent event) {
        if ((keyCode == KeyEvent.KEYCODE_BACK) && webView.canGoBack()) {
            webView.goBack();
            return true;
        }
        return false;
    }
}

In this case, it seems that I must "Opening index.html over file://", so I first need to do some settings

• In the project config.js file, change the value of the assetsPublicPath field to the relative path './'
• Adjust the location of static resources such as images in the generated static folder to be consistent with the reference address in the code
  

This is an obvious change that needs to be made, but it still cannot be loaded successfully after the change. After repeated investigation, it was found that when the project was developed, the router was set to history mode (for aesthetics...0_0"). When it was changed to hash mode, it can be loaded normally.

Why does this happen? I analyzed the reasons as follows:

When loading index.html directly from the file system, the URL is:

file:///android_asset/index.html

The path that the home page view needs to match is path: '/' :

export default new Router({
  mode: 'history',
  routes: [
    {
      path: '/',
      name: 'index',
      component: IndexView
    }
  ]
})

Let's first look at the history mode, in HTML5History:

ensureURL ( push?: boolean ) {
  if (getLocation(this.base) !== this.current.fullPath) {
    const current = cleanPath(this.base + this.current.fullPath)
    push ? pushState(current) : replaceState(current)
  }
}

export function getLocation (base: string): string {
  let path = window.location.pathname
  if (base && path.indexOf(base) === 0) {
    path = path.slice(base.length)
  }
  return (path || '/') + window.location.search + window.location.hash
}

The logic only ensures that the URL exists. The path is obtained directly from window.location.pathname by cutting it. It ends with index.html, so it cannot match '/', so "Opening index.html over file:// won't work".

Let’s look at the hash mode again. In HashHistory:

export class HashHistory extends History {
  constructor (router: Router, base: ?string, fallback: boolean) {
    ...
    ensureSlash()
  }

  // this is delayed until the app mounts
  // to avoid the hashchange listener being fired too early
  setupListeners() {
    window.addEventListener('hashchange', () => {
      if (!ensureSlash()) {
        return
      }
      ...
    })
  }

  getCurrentLocation() {
    return getHash()
  }
}

function ensureSlash (): boolean {
  const path = getHash()
  if (path.charAt(0) === '/') {
    return true
  }
  replaceHash('/' + path)
  return false
}

export function getHash(): string {
  const href = window.location.href
  const index = href.indexOf('#')
  return index === -1 ? '' : href.slice(index + 1)
}

We can see that in the code logic, a function ensureSlash() appears many times. When the # symbol is followed by '/', it returns true, otherwise the '/' is forcibly inserted. Therefore, we can see that even if index.html is opened from the file system, the URL will still become the following form:

file:///C:/Users/dist/index.html#/

The path returned by the getHash() method is '/', which matches the route of the home view.

Therefore, if you want to load a Vue single-page application directly from the file system without the help of a backend server, in addition to some path settings after packaging, you also need to ensure that vue-router uses hash mode.

The above is the details of the two implementations of front-end routing from the perspective of vue-router. For more information about the two implementations of vue front-end routing, please pay attention to other related articles on 123WORDPRESS.COM!