onhashchange 与 pushState答案

【问题标题】：onhashchange vs pushStateonhashchange 与 pushState
【发布时间】：2014-05-10 00:37:35
【问题描述】：

我正在我的网站上创建一个内部仪表板，该仪表板仅供登录用户访问，因此无法被搜索引擎索引/抓取。这个仪表板主要是一个单页应用程序。此外，我不关心（至少我不认为我关心）漂亮的 url：没有渐进增强 - 如果禁用 javascript，那么仪表板将不起作用。

我需要的是能够使用后退/前进按钮在不同状态之间导航 - 例如，打开的各种模式。非常重要的是，我需要能够将 externally 链接到仪表板的特定状态（例如，在此配置中打开了模态 A） - 例如通过电子邮件发送给包含仪表板链接的用户。

考虑到这一切，对于“老派”哈希刘海（#！）与 html5 pushState 有什么偏好吗？ pushState 无论如何都会要求我使用类似 history.js 的东西来支持旧的浏览器。从架构上讲，如果我的仪表板位于以下网址：

http://example.com/dashboard

无论我使用的是 pushState 还是 onhashchange，我是否都必须执行几乎相同的操作才能解析到特定的模态状态？换句话说：

http://example.com/dashboard#!modalA/state1

或

http://example.com/dashboard/modalA/state1

这两者都需要解析客户端（由框架完成）以确定如何显示当前仪表板状态。我的后端控制器仍将映射到 /dashboard/* 的任何仪表板 url，因为所有状态问题都在客户端处理。

我错过了什么吗？没关系，但我使用的是CanJS，它同时支持哈希事件和 pushState。

注意：我的问题不是针对 Google 的 hashbang 提案，而是针对 # (onhashchange) 的一般用法。

【问题讨论】：

好吧，如果您有多个页面，我建议您在主题标签上使用 pushState，因为如果您有一个页面，例如 /dashboard/settings，当用户刷新页面时，服务器可以读取它们'重新请求设置页面，服务器可以将其吐出，而不是使用 /dashboard#settings，主题标签不会发送到服务器，因此用户必须先加载索引页面，然后渲染设置页面，即由于存在延迟，因此用户体验不佳。此外，如果您要使用模式，您可以使用查询字符串，例如 /dashboard?modal=show
哈希爆炸是a lie。不要使用它们。
老浏览器的支持也是骗人的。虽然网站的公共部分可能会扩展对复古浏览器的支持，但诸如“仪表板”之类的应用程序（几乎总是由知道为什么应该更新浏览器的人使用的应用程序）可以使用可用的最新稳定功能。总而言之连IE10（2岁多）supportshistory API
关于哈希爆炸的有趣点。但是，我应该在我的帖子中指出，我的问题同样适用于任何 onhashchange 的使用，而不一定是谷歌的 hash bang 提案
好吧，对于您的特定任务，我真的没有看到任何更好的方法。两者都可以满足您的所有需求。就我个人而言，我喜欢历史 API，因为它可以使链接看起来更好，这确实是最重要的区别。

标签： javascript hash browser-history pushstate

【解决方案1】：

This article 很好地总结了使用 hash/hashbang 的潜在问题，尽管它对它们有很大的偏见——通常是有充分理由的。

鉴于以下情况，你处于一个非常幸运的位置：

您不必担心 SEO 问题
您的应用在您的组织内部

对我来说，这使您的选择非常明确，具体取决于您是否可以要求组织内的人员将他们的浏览器升级到与 HTML5 兼容的版本（如果他们还没有的话）。因此，如果您有这种能力，请使用 HTML5 History api。如果不这样做，请使用哈希。如果您希望 HTML5 pushState 带有 HTML4 onhashchange 回退，you can do that as well 虽然需要一些额外的工作来确保您的所有 HTML5 链接都适用于 HTML4 用户。

【讨论】：