关于Hash和History两种路由模式原理的精简笔记

271 阅读2分钟

本篇文章是关于HashHistory两种模式原理的精简笔记,可用于速记和复习

来由

由于传统的浏览器URL变化是会向服务端重新请求并刷新页面,不同的URL对应不同的页面、不同的资源,导致每次路由切换的时候都会去刷新页面,用户体验很差;所以为了提升用户体验,前端路由就出现了。

HashHistory对应于SPA(单页面)应用的两种路由模式,它们的本质都是改变浏览器URL且不刷新页面,监听其变化,触发自定义的路由处理方案。

Hash模式原理

首先Hash就是常见的地址栏中的#后面的字符,location.hash获取和设置hash值,原本是用来做页面定位的,称之为锚点,能够使页面定位到对应id的元素。Hash相较于History推出较早。路由的Hash模式的原理如下:

  • 使用hash值来匹配对应路由
  • hash值的改变不会使浏览器刷新
  • 使用hashChange来监听hash值的变化,从而触发自定义的路由处理方案,浏览器的前进后退也会触发hashChange
  • 比较老的方案,兼容性没问题

History原理

History是H5推出的API,兼容性没有Hash好,主要是利用popState事件来监听历史栈的变化,gobackforward能够触发该事件从而触发自定义的路由处理方案,pushStatereplaceState会改变URL但不会触发该事件,需要手动触发自定义的路由处理方案。原理如下:

  • 使用history的新API来进行处理,新API如下:
    • gobackforward
    • pushStatereplaceState 其中gobackforward才会触发popState事件
  • pushStatereplaceState会改变浏览器地址但不会让浏览器刷新
  • history路由的实现逻辑就是,手动的跳转使用popStatereplaceState,并且主动触发自定义的路由处理方案;浏览器点击的跳转触发popState事件从而触发自定义的路由处理方案。
  • H5的新API,对于IE有兼容性
  • 刷新会有问题,需要服务端支持,假如不是首页路径,就会出错;需要后端处理成:遇到不认识的路径也返回相同的html