spa前端路由的演变与实现机制

spa是什么

百科：单页Web应用（single page web application，SPA），就是只有一张Web页面的应用，是加载单个HTML 页面并在用户与应用程序交互时动态更新该页面的Web应用程序。

单页的页面即为一个html页面，可以理解为，某个应用中所有的其他页面和单元均为一个预设好的根页面的子组件，通过js，css来控制众多子组件的替换和更新，从而达到模拟页面跳转的情景。我把这种应用称之为spa。

前端路由的进化

提到了前端路由就不得不提到后端路由，一个后端路由可以理解为一个url发起一个请求，获取数据（html模板，文本信息，图片等）然后通过控制器处理后再向浏览器渲染处理过后的页面，就会出现一个新的页面。这个过程就是所谓的ssr。然后前端向后端请求资源的方式就是后端路由了。

后端路由的弊端

但是很明显，每次需要更新页面都需要发起新的请求，服务器压力会很大，如果网络状况不好，还会造成极差的用户体验。
但是，当Ajax出现之后，这种交互方式慢慢发生了改变。利用Ajax的异步加载的机制，可以不需要刷新页面即可发送新的请求。从而实现spa，提高用户体验，减少服务端压力。

未利用前端路由的spa的弊端

凡事有利有弊，当时的spa也有自己的劣势：

• spa无法记住用户的操作，前进后退，刷新都无法展示用户期待的内容
• spa会有多种业务页面，一个url，seo不友好，不利于搜索引擎进行收录

于是渐渐演化出了前端路由来解决上述两个问题。
前端路由的目的：

• 当我们改变url的时候，浏览器不会向服务器发起请求
• 实时监听url的变化

前端路由的实现机制

• 监听url中hash值得变化
• HTML5 history模式

hash

hash值得改变不会导致浏览器向服务器发送请求，并且改变的时候会触发hashchange事件，hashchange可以捕捉url的变化，从而实现spa。

https://blog.csdn.net/JaxHu/#collection-list

举例，#collection-list 就是hash值，在H5的history模式出现之前，前端路由基本都是用hash模式来实现的。

history

History 路由是基于 HTML5 规范，在 HTML5 规范中提供了 history.pushState和history.replaceState 来进行路由控制。当你执行

history.pushState({}, null, ‘/home’) 

页面 url 会从

 http://localhost:8080/ 

跳转到

  http://localhost:8080/home 

可以在改变 url 的同时，并不会刷新页面。

先来简单看看 pushState 的用法，参数说明如下：

• state：存储 JSON 字符串，可以用在 popstate 事件中
• title：现在大多浏览器忽略这个参数，直接用 null 代替
• url：任意有效的 URL，用于更新浏览器的地址栏

hash和history的对比

• hash兼容性高，甚至可以兼容到老版本的IE浏览器

• history是基于H5的实现模式，对低版本浏览器不一定兼容

• hash模式会在url中夹带#符号，看起来多多少少会有些不自然

• history模式不会有这种情况

总结

具体的实现可以去看看其他大佬的文章，此文不做详述。总之前端路由的目的是为了页面无刷新，并且可以进行页面的更替。