监控 location.hash 是 XHR 应用中历史的解决方案吗? [英] Is monitoring location.hash a solution for history in XHR apps?

问题描述

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

As is well known, in XHR (aka AJAX) web applications no history for your app is build and clicking the refresh button often moves the user out of his/her current activity. I stumbled upon location.hash (e.g. http://anywhere/index.html#somehashvalue) to circumvent the refresh problem (use location.hash to inform your app of it's current state and use a page load handler to reset that state). It's really nice and simple.

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

This brought me to thinking about using location.hash to track the history of my app. I don't want to use existing libraries, because they use iframes etc. So here's my nickel and dime: when the application page loads I start this:

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 (<= 7) 中则不会.在所有浏览器中，向后或向前导航到具有另一个哈希值的页面不会触发页面刷新.这就是间隔函数接管的地方.每次检测到哈希值更改时(以编程方式，或通过单击后退或前进)，应用程序都可以使用该功能采取适当的措施.应用程序可以跟踪它自己的历史记录，我应该能够在应用程序中显示历史记录按钮(尤其是对于 IE 用户).

(appCache is a predefined object containing application variables) The idea is to trigger every action in the application from the hash value. In decent browsers a hash value change adds an entry to the history, in IE (<= 7) it doesn't. In all browsers, navigating back or forward to a page with another hash value doesn't trigger a page refresh. That's where the intervalled function takes over. With the function everytime the hash value change is detected (programmatically, or by clicking back or forward) the app can take appropriate action. The application can keep track of it's own history and I should be able to present history buttons in the application (especially for IE users).

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

As far as I can tell this works cross browser and there's no cost in terms of memory or processor resources. So my question is: would this be a viable solution to manage the history in XHR-apps? What are the pros and cons?

更新:因为我使用自制框架，我不想使用现有框架之一.为了能够在 IE 中使用 location.hash 并将其保存在历史记录中，我创建了一个简单的脚本(是的，它需要一个 iframe)，它可能对您有用.我在我的网站发布了它，请随意使用/修改/批评它.

Update: because I use my homebrew framework, I didn't want to use one of the existing frameworks. To be able to use location.hash in IE and having it in it's history too, I created a simple script (yes, it's needs an iframe) which may be of use to you. I published it on my site, feel free to use/modify/critizise it.

推荐答案

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

I think you'll have a tricky time knowing if a user went forward or back. Say the url starts /myapp#page1 so you start tracking states. Then the user does something to make the url /myapp#page2 Then the user does something to make the url /myapp#page1 again. Now their history is ambiguous and you won't know what to remove or not.

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

The history frameworks use iframes to get around the browser inconsistencies you mentioned. You only need to use iframes in the browsers that need them.

另一个缺点是用户总是会先选择浏览器的后退按钮，然后再选择您的自定义后退按钮.我感觉每 250 毫秒读取一次历史记录的延迟也会很明显.也许您可以将间隔做得更紧，但我不知道这是否会使事情表现不佳.

Another con is that users will always go for their browsers back button before they will go for your custom back button. I have a feeling the delay on reading the history every 250ms will be noticeable too. Maybe you can do the interval even tighter, but then I don't know if that'll make things perform badly.

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

I've used yui's history manager, and although it doesn't work perfectly all the time in all browsers (especially ie6), it's been used by a lot of users and developers. The pattern they use is pretty flexible too.

这篇关于监控 location.hash 是 XHR 应用中历史的解决方案吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！