监控 location.hash 是 XHR 应用中历史的解决方案吗？

Question

众所周知，在 XHR（又名 AJAX）Web 应用程序中，不会为您的应用程序构建历史记录，并且单击刷新按钮通常会使用户退出他/她当前的活动。我偶然发现了 location.hash（例如http://anywhere/index.html#somehashvalue）来规避刷新问题（使用 location.hash 来通知您的应用程序它的当前状态并使用页面加载处理程序来重置该状态）。真的很好很简单。

这让我想到了使用 location.hash 来跟踪我的应用程序的历史记录。我不想使用现有的库，因为它们使用 iframe 等。所以这是我的五分钱：当应用程序页面加载时，我开始这样做：

setInterval(
       function(){
           if (location.hash !== appCache.currentHash) {
               appCache.currentHash = location.hash;
               appCache.history.push(location.hash);
               /* ... [load state using the hash value] ... */
               return true;
           }
           return false;
       }, 250
 );

(appCache 是一个包含应用程序变量的预定义对象) 这个想法是从哈希值触发应用程序中的每个动作。在体面的浏览器中，哈希值更改会在历史记录中添加一个条目，而在 IE (

据我所知，这可以跨浏览器工作，并且在内存或处理器资源方面没有成本。所以我的问题是：这是否是管理 XHR 应用程序历史的可行解决方案？有什么好处和坏处？

更新：因为我使用自制框架，我不想使用现有框架之一。为了能够在 IE 中使用 location.hash 并将其也包含在它的历史中，我创建了一个简单的脚本（是的，它需要一个 iframe），它可能对您有用。我发布了它on my site，请随意使用/修改/批评它。

Answer 1

所有这些对于支持全系列浏览器都很重要，但希望对它的需求会消失。 IE8 和 FF3.6 都引入了对onhashchange 的支持。我想其他人也会效仿。在使用超时或 iframe 之前检查此功能的可用性是个好主意，因为它确实是目前最好的解决方案 - 它甚至可以在 IE 中使用！

Answer 2

大多数解决方案往往会同时解决 3 个问题：

1. 返回按钮
2. 书签性
3. 刷新按钮

在大多数情况下，基于window.location.hash 的解决方案可以解决所有三个问题：hash 中的值映射到应用程序/网页的状态，因此用户可以按“后退”/“前进”/”中的一个刷新”并跳转到哈希中的状态。他们还可以添加书签，因为地址栏中的值已更改。 （请注意，与不影响浏览器历史的哈希相关的 IE 需要隐藏 iframe。

我只是想指出，一个仅 iframe 的解决方案可以在不监视 window.location.hash 的情况下使用，这也是一个非常有效的解决方案。

谷歌地图就是一个很好的例子。为每个用户操作捕获的状态太大而无法放入 window.location.hash（地图质心、搜索结果、卫星与地图视图、信息窗口等）。因此他们将状态保存到嵌入隐藏的iframe 的表单中。顺便说一句，这也解决了[软]“刷新”问题。他们通过“链接到此页面”按钮单独解决书签问题。

我只是认为值得了解/分离您正在考虑的问题域。

Answer 3

我认为您很难知道用户是前进还是后退。 假设 url 开始 /myapp#page1 所以你开始跟踪状态。 然后用户做一些事情来制作 url /myapp#page2 然后用户做一些事情来再次制作 url /myapp#page1。现在他们的历史是模棱两可的，你不知道要删除什么。

历史框架使用 iframe 来解决您提到的浏览器不一致问题。您只需要在需要它们的浏览器中使用 iframe。

另一个缺点是用户总是会先选择浏览器的后退按钮，然后再选择您的自定义后退按钮。我感觉每 250 毫秒读取一次历史记录的延迟也会很明显。也许你可以把间隔做得更紧，但我不知道那会不会让事情变得糟糕。

我使用过 yui 的历史管理器，虽然它在所有浏览器（尤其是 ie6）中并不是一直都能完美运行，但它已经被很多用户和开发者使用。他们使用的模式也非常灵活。