哪一个更好的pushstate或location.hash？

Question

window.location.hashvs HTML5 history.pushState.使用ajax请求满足url哪个更好,为什么？谢谢.

Answer 1

location.hash有比这个history.pushState方法更好的支持.
该pushState方法的优点是您可以将状态绑定到历史记录条目.
如果您不需要此状态对象,我建议使用该location.hash属性,以便与旧版浏览器更好地兼容.

location.hash = 'new-hash';
console.log(history.state); // null or undefined

history.pushState({extraData: "some state info"}, '', 'new-hash'); //<---
console.log(history.state); // [object Object] = {"extraData": "some state info"}

Answer 2

Pushstate是未来.它更好,因为:

1. 它看起来更干净.
2. 重新访问深层链接,您实际上可以显示真实的服务器端数据,以支持SEO和Facebook Open Graph等内容(两者都会发送蜘蛛来抓取您网页的HTML).
3. 服务器无法访问哈希标记数据,因此您不会在服务器日志中看到它,因此它可以帮助一些人进行分析.
4. 它有助于修复哈希标记问题.例如,我进行了Nginx重写,将访问我的应用的用户重定向到相同的https网址.它适用于所有浏览器,但Safari会将您重定向到没有哈希的域(非常烦人)!
5. 您实际上可以使用哈希标记来实现目的,深层链接到长页面的部分.
6. 您可以回退使用不支持推送状态的浏览器的真实HTTP后端请求,或者您可以回退到使用哈希标记.两者都需要额外的实施,但很容易做一点工作.

有关更多内容,请参阅Github设计师的演讲:http://warpspire.com/talks/responsive/

Answer 3

history.pushState比...更好location.hash.但它是HTML5功能.所以总是更好的有一个像下面这样的后备方法.

if (typeof(window.history.pushState) == 'function') {
    window.history.pushState(null, path, path);
} else {
    window.location.hash = '#!' + path;
}

Answer 4

我同意其他答案,但这里有一些赞成的 论据location.hash:

• 它适用于所有浏览器,包括Internet Exploder ^TM
• history.pushState是一个开发标准,API可能在将来发生变化
• 如果用户在新窗口/选项卡中打开链接,则哈希URL确保加载页面不需要服务器请求(如果设置了正确的缓存头)
• 服务器配置很简单,因为所有服务器都看到的是没有hash-part的URL

编辑:我忘了一个

• 使用主题标签,您可以使用真实的链接(a href).因此,您不必设置单击侦听器,从而提高性能并减少代码大小.

Answer 5

window.location.hash与HTML5 history.pushstate的优缺点很大程度上取决于您希望页面降级的程度.

在这里,您可能对两种不同场景中的优雅降级感兴趣:

第一个是没有启用javascript的客户端,或者访问您网站的自动化bot/crawler.从SEO的角度来看,这一点尤为重要.如果您的网页/网络应用程序使用哈希网址,则这些最终用户无法使用通过这些链接提供的内容.如果您只通过没有回退的hash-url创建内容部分,这肯定是一个问题.但是,如果您使用哈希标记链接来修改应用程序状态,如果页面降级则不会保留意义,那么这绝对不是问题.

作为一个示例,考虑一个场景,其中您在一个选项卡式布局小部件中的三个选项卡中有一个包含三个文本部分的页面.现在有两种可能的情况:在第一种情况下,您将在页面加载期间加载所有内容 - 而选项卡式窗口小部件将仅用于隐藏其他部分并显示特定部分.因此,如果您在用于构建选项卡拇指的链接中使用hash-urls,则仅使用它们来更改客户端应用程序状态.当javascript被关闭/不可用时,只是用于构建选项卡式布局的javascript不会运行,并且所有内容都立即可用 - 一个合理的优雅后备.在这种情况下,不同的应用程序状态根本不存在,因此hash-urls会降级为仅指向html中的锚点 - 预期目的.如果你在这种情况下使用html5 pushstate而不是hash-urls,那将是一个坏主意.用户可能将链接添加到特定选项卡的链接的原因.因为您的服务器必须获取该URL并向用户显示他期望的客户端状态.这对于瘦客户端应该处理自己的状态管理的瘦服务器体系结构来说并不好.您可以在服务器端忽略该方面,让客户端在页面加载时检查URL,然后切换到适当的应用程序状态.但它仍然不是一个好主意,因为你的服务器端路由系统关注它应该忽略的额外url片段的开销,因为从美学的角度来看它根本不应该被打扰.这完全映射到设计hash-urls的要求,强烈建议使用它们.如果在三个部分中,当单击特定选项卡缩略图时动态加载文本,则使用hash-url不是一个好主意.原因是如果javascript不可用,用户将无法访问链接的内容.这对SEO来说特别糟糕.在这种情况下,如果您处理服务器端的URL(在正常情况下会被"劫持"和"ajaxified")以使内容一般可用,从最终用户体验和SEO的角度来看它都是极好的.

第二种情况是客户端有一个不支持html5 pushstates的过时浏览器.虽然以上几点仍然有效,但我还认为强迫没有pushstate的用户具有与no-javascript相同的降级水平是不合理的.许多最终用户根本不知道为什么他们会收到降级版本.

我建议你不要随意使用最新技术的教条,并为你的使用场景决定最佳选择.

Answer 6

这是一个相当老的问题（在此答复时为5年以上），但是对现有答复的许多评论都要求根据事物的“当前”状态进行更新。

这是交易：

所有主要浏览器均支持HTML5的pushState。如果您也支持较旧的浏览器，history.js提供了一个很好的polyfill，可让您本地使用pushState并轻松将其回退到较旧浏览器的旧版URL。但是，现在原生支持pushState并不意味着它绝对是要走的路。

有一个非常重要的观点，在任何较早的答案中都没有提到，即哈希URL和pushState URL不仅在外观上有所不同，而且在工作方式上也实际上有所不同。两者之间的根本区别可能会导致您选择一个。

pushState漂亮，整洁，可用于完全假冒您网站/应用程序中的导航。例如，GitHub使用它来隐式替换所有导航。当您单击其站点上的任何链接时，javascript将被用来拦截该单击并将其转换为AJAX请求，该请求可更新页面内容而无需加载新页面，而位置栏中的URL会更改为与以前拿来。这就是pushState的用途。

对于GitHub，http：// mysite / page1和http：// mysite / page2都是有效的URL。它们是具有“真实”内容的“真实”链接，并且最初访问任一页面都是通过传统的MVC方法进行的。GitHub在现代浏览器中使用pushState进行导航，但并不需要这样做-即pushState用作“功能添加”（在他们看来），可以带来更好的导航用户体验。当您在浏览器地址栏中复制链接时，您将复制通过javascript＆pushState形成的链接，但是该链接仍然是真实有效的。

但是，如果您是从头开始创建单个页面的应用程序，并且未使用MVC框架，则很有可能实际上只有一个页面，特别是如果您不使用动态后端（即，所有内容均通过javascript检索） ，永远不会由服务器生成）。在这种情况下，如果对哈希网址使用pushState，则需要处理浏览器中的URL不是真实URL的情况。我会举例说明。

用户加载您的单页应用程序：http：// mysite / mainpage

此时，浏览器栏包含指向您应用的真实链接，并将用户带至他们当前看到的相同视图：主页。现在，他们单击一个链接，该链接会将他们带到显示某些活动详细信息的“页面”。此时，您想更新位置栏以指示状态更改。您可以使用一个哈希URL，并且您的位置栏看起来像http：// mysite / mainpage＃charts / 1，或者您可以使用pushState诱使它成为http：// mysite / mainpage / charts / 1

如果您使用pushState，则这不是真正的link。通过浏览器的后退/前进按钮进行导航将非常有用，并且用户将在位置栏和应用程序中从主页转到详细信息页面（假定您正确处理了状态更改），但是如果用户将该链接添加为书签或复制并粘贴链接以共享它，则需要其他服务器端伏都教。

您将需要将请求重定向到/ mainpage / charts / 1到/ mainpage，然后使用JS解析实际的URL并执行预期的状态更改操作。绝对需要服务器重定向。如果没有可编写脚本的http服务器，则无法在AWS或本地磁盘上托管此页面。

现在，如果您使用哈希网址，那么用户可以看到并与之交互的网址就是http：// mysite / mainpage＃/ charts / 1 ，这是一个有效的真实网址。浏览器了解只有一页，并且无论用户是复制并粘贴链接还是对其添加书签，您只需要处理javascript中的哈希状态，并且不需要任何服务器端魔术即可使工作正常。

似乎没有人提到的是pushState和哈希链接不是互斥的。pushState只是一个API，用于操纵用户可见的浏览器位置并在现代浏览器中实现可靠的后退/前进导航。它没有说明您的URL方案应该是什么样子。

在2017年，Google和几乎所有其他具有JS功能的bot都能理解哈希URL并遍历它们。Google希望您使用＃！出于SEO最大化目的而憎恶，但即使您不这样做，您的网站也可以正常浏览。

正确的答案是使用最适合您的需求。如果您有真实的URL，并且想要伪造它们之间的导航，请使用pushState并继续（对于较旧的浏览器，可以选择使用polyfill）。但是，如果您使用的是单页应用程序，请不要假装不这样做（除非您有充分的理由）。使用哈希URL可以使您的生活更轻松，并且不会引入不必要的问题，然后使用pushState操纵这些哈希URL以利用更好的后退/前进支持。