对前端路由选择的思考

[func-star]

前言

随着 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 来做页面的跳转和回退。

介绍的比较粗浅，仅代表个人的一些使用总结