reactrouter监听路由变化_监听history.push/replaceState和local/sessionStorage变化

前端路由我们都已经很熟悉了，像Vue、React等一些MVVM框架都提供了前端路由支持，使得前端开发更加独立高效。

前端路由的原理我们都知道，一般面试的时候也经常会被问起。我们一般都会回答：前端路由有两种，一种是 hash 模式，原理是监听 window 上的 onhashchange 事件来实现视图更新，一种是 history 模式，原理是使用 history.pushState/replaceState 来实现 url 变化， window 上的 onpopstate 事件来实现视图更新。如果你这么回答，那么恭喜你，你可以回家等通知了。

实际的情况是 history.pushState/replaceState 并不会触发 onpopstate 事件，onpopstate 只有用户点击浏览器后退和前进按钮时，或者使用js调用back、forward、go方法时才会触发。那么我们如何监听 history.pushState/replaceState ？

答案是：重写 + 自定义事件

重写 history.pushState/replaceState 使其在执行后触发一个自定义事件，我们通过监听这个自定义事件来接收视图变化通知，上代码：

// 重写方法

代码实现参考： https://juejin.im/post/5c2708cd6fb9a049f06a5744

这样就可以实现对 history.pushState/replaceState 的监听了。

根据这样的实现方式，我又想起来了之前封装过一个 Proxy + WebStorage 的小工具，不过因为太久没有用已经不维护了，如果感兴趣的话可以的看这里：https://juejin.im/post/5d48179df265da03ba3227d6

在封装过程中随着对 WebStorage 的理解加深，我发现：当我们通过 WebStorage API 对 WebStorage 进行增删改查的操作并不能被事件精确监听。为什么说不能精确监听呢？因为可以监听，但是不精确。只有 localStorage 的变动才能被 storage 事件监听到，且因为浏览器的不同，实现的标准都有所不同，比如 Chrome 只允许跨页面的触发和监听，而IE和火狐允许同页面监听。这个 API 的使用场景可以看我的另一篇专栏：

尹成诺：同一个域下在浏览器不同Tab的页面如何通信？​zhuanlan.zhihu.com

而我想实现的是，同页面的 storage，同时不仅仅只能监听到 localStorage ，还能监听到 sessionStorage。不要问我实现这些有什么用，我只能说：以防万一。毕竟需求是不可控的，我也在一篇介绍 WebStorageProxy 的文章中提到过：https://juejin.im/post/5d48179df265da03ba3227d6#heading-8 。当时做这个库，其实也实现了同页面所有 storage 操作的监听，思路也是重写原生方法。但是我是重写的 Storage.prototype 上的 clear、getItem、setItem、removeItem 方法，由于 local Storage 和 sessionStorage 都是 Storage 的实例。因此在运行时，很难去判断到底是 localStorage 还是 sessionStorage 调用了 Storage 原型上的方法。因此重写原型方法并不解决问题，还有污染原型链的嫌疑。因此，重写原型链方法并不是最理想的方式。

相对更好的方式是在实例上添加操作方法，即分别在 localStorage 对象和 sessionStorage对象上添加 clear、getItem、setItem、removeItem 方法，比如 sessionStorage 的 setItem 方法：

// 重写方法

这样，就实现了同页面下 set sessionStorage 的监听，同理其他操作及 localStorage 的监听也是同理。