In Vue routing, what is the difference between history and hash modes?

There are two modes of front-end routing: hash mode and history mode. Next, we will analyze the implementation methods, advantages and disadvantages of these two modes.

hash pattern

Hash mode is a mode in which the path of the front-end route  # is spliced ​​with hash marks behind the real URL. When the path after the hash sign  # changes, the browser will not re-initiate the request, but will trigger  hashchange an event.

Example :

Create a new  hash.html file with the following content:

<a href="#/a">A页面</a>
<a href="#/b">B页面</a>
<div id="app"></div>
<script>
  function render() {
    app.innerHTML = window.location.hash
  }
  window.addEventListener('hashchange', render)
  render()
</script>

In the above example,  a two route navigations are set up using labels, which are used  app as view rendering containers. When the route is switched, the update of the view container is triggered. This is actually the implementation principle of hash routing in most front-end frameworks.

Summarize the advantages and disadvantages of hash mode:

• Advantages : Good browser compatibility, even IE8 is supported
• Disadvantages : The path is  # behind the pound sign, which is ugly.

history mode

The history API is a new feature provided by H5, which allows developers to directly change the front-end routing, that is, update the browser URL address without reinitiating the request.

Example :

Create a new one  history.htmlwith the following content:

<a href="javascript:toA();">A页面</a>
<a href="javascript:toB();">B页面</a>
<div id="app"></div>
<script>
  function render() {
    app.innerHTML = window.location.pathname
  }
  function toA() {
    history.pushState({}, null, '/a')
    render()
  }
  function toB() {
    history.pushState({}, null, '/b')
    render()
  }
  window.addEventListener('popstate', render)
</script>

The history API provides a wealth of functions for developers to call. You might as well open the console and enter the following statement to observe changes in the browser address bar:

history.replaceState({}, null, '/b') // 替换路由
history.pushState({}, null, '/a') // 路由压栈
history.back() // 返回
history.forward() // 前进
history.go(-2) // 后退2次

The above code listens to  popstate the event, and the event can be monitored:

• User clicks the browser's forward and back actions
• Manually call the history  back, forward and  go methods

Unable to monitor:

• pushState The sum  replaceStatemethod of history 

This is also why the above  toA and  toB functions need to call  render methods manually. In addition, you may also notice  light-server that the command has more  --historyindex '/history.html' parameters. What does this do?

When the browser refreshes, it will send a real resource request according to the path. If the path is the URL set by the front end through the history API, then the resource often does not exist on the server side, so 404 will be returned. The above parameters mean  history.html what will be returned if the backend resource does not exist.

Therefore, when deploying a single-page application based on the history API online, the backend must cooperate with the support, otherwise a large number of 404s will appear. Taking the most commonly used Nginx as an example, you only need to  location / add the following line to the configuration:

try_files $uri /index.html;

Summarize the advantages and disadvantages of history mode:

• Advantages : The path is relatively formal and there are no hash marks. #
• Disadvantages : The compatibility is not as good as hash, and it needs server support, otherwise it will get 404 as soon as the page is refreshed.