history.js 源码分析(一) - 原理解析

604 阅读1分钟

单页应用与多页应用的架构演进

单页应用架构的设计是催生 history 发展的一个重要原因
在多页架构中。服务器可以根据请求报文直接定位到文件,从而展示不同的页面内容。 未命名文件 (12).png 在单页架构中,构建结果只有一个 HTML 文件。当访问到 index.html 之后,服务器就帮不上什么忙了。 未命名文件 (11).png 所以,就出现了前端路由的概念
用于在浏览器内部就能维护好 URL 与显示内容之间的映射关系,接着由视图层框架将组件变成 HTML DOM 节点插入到根节点下就完成了内容的切换。未命名文件 (13).png 定好了 URL 与组件的映射关系,定好了组件插入到 DOM 的方法,还差最后一步确定 URL 变化的通知回调,这样才能准确无误的更新组件的内容。

怎样能改变 URL 呢?

理论上来说只要在变化之后调用统一的方法,就可以实现完备的 URL 变化通知回调了。 那我们先把能改变 URL 的行为都罗列出来,然后给他们分各类,再看看他们的监听方法。

screenshot-20211214-080634.png

那看完这个表之后呢,结论就是
我们只要在 onLoad 和 popState 做事件委托,然后在每次调用 history.pushState 和 history.replaceState 之后做统一通知就好啦。

分析源码之前,先来实现一个伪代码

carbon (14).png