-
Notifications
You must be signed in to change notification settings - Fork 1
Description
前言
随着 SPA
广泛应用在前端项目中,前端路由这个概念也伴随着火了起来。
这家伙目前主要是通过 hash
和 hitory api
这两个玩意实现,具体怎么实现的,后面稍微介绍一下。
本文不对这两个实现方案的好坏做过多评价,我依然觉得技术没有好坏,只有在具体的时间阶段和场景下,哪个更加合适一些。
接下来我来介绍一下这两个玩意的应用背景。
hash
到 history
的变迁
在 SPA
单页面应用兴起的时候,大家都在寻找一个可以切换页面,且不会触发页面刷新的方案。
据我了解,hash
在被应用到前端路由之前,主要是被应用在页面锚点定位。
因为 hash
的url
信息携带主要依赖 #
下面的字符,前端系统可以通过 js
解析页面路径信息来处理后续的逻辑,所以应该是当时的最优解决方案。
例如:http://monajs.cn/docs/#home
后来,HTML5
中新添加了 History api
,它支持切换和修改历史状态。主要通过 back
、forward
、go
三个方法,对应浏览器的前进,后退,跳转操。
修改历史状态包括了 pushState
, replaceState
两个方法,这两个方法接收三个参数:stateObj
,title
,url
。
history.pushState({name: 'yangxi'}, 'title', 'url')
window.addEventListener('popstate', (e) => {
if (e.state && e.state.name === 'yangxi') {
return
}
//TODO
}, false)
从代码中可以看到,我们通过 history
做页面跳转的时候,可以携带信息,而且不像 hash
跳转那样只能携带有限的字符信息。stateObj
可以携带各种数据对象。
这是
history api
对前端路由切换的一次全新赋能。
另一方面,使用 history api
来设计前端路由,改善了之前 #***
的这种 hash
形式。一定程度上来讲美观了不少😄😄😄😄
以上特性,是我比较喜欢 history api
设计前端路由的重要理由,我自己也实现了一套基于 history api
的 react-router,有兴趣的朋友可以看一下。
前端路由实现思路
接下来我简单讲一下 router
的实现思路。
其实自己实现一个简单的 router
是比较简单的,我们只需要能监听到 url
的变化,然后对 url
进行一堆格式化分析,然后去匹配对应的页面实例。
hash
实现
hash
实现路由是通过监听hashchange
事件实现的,然后页面之间跳转则可以通过location.hash
来做。history
事件
history
实现路由是通过监听popstate
事件实现的,然后通过history api
提供的pushState
和replaceState
来做页面的跳转和回退。
介绍的比较粗浅,仅代表个人的一些使用总结