問題描述

眾所周知，在 XHR(又名 AJAX)Web 應(yīng)用程序中，不會(huì)為您的應(yīng)用程序構(gòu)建歷史記錄，并且單擊刷新按鈕通常會(huì)使用戶退出他/她當(dāng)前的活動(dòng).我偶然發(fā)現(xiàn)了 location.hash(例如 http://anywhere/index.html#somehashvalue)來規(guī)避刷新問題(使用 location.hash 通知您的應(yīng)用程序的當(dāng)前狀態(tài)并使用頁面加載處理程序來重置該狀態(tài)).真的很好很簡單.

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 來跟蹤我的應(yīng)用程序的歷史記錄.我不想使用現(xiàn)有的庫，因?yàn)樗鼈兪褂?iframe 等.所以這是我的五分錢:當(dāng)應(yīng)用程序頁面加載時(shí)，我開始這樣做:

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 是一個(gè)包含應(yīng)用程序變量的預(yù)定義對(duì)象) 這個(gè)想法是從哈希值觸發(fā)應(yīng)用程序中的每個(gè)動(dòng)作.在體面的瀏覽器中，哈希值更改會(huì)在歷史記錄中添加一個(gè)條目，而在 IE (<= 7) 中則不會(huì).在所有瀏覽器中，向后或向前導(dǎo)航到具有另一個(gè)哈希值的頁面不會(huì)觸發(fā)頁面刷新.這就是間隔函數(shù)接管的地方.每次檢測到哈希值更改時(shí)(以編程方式，或通過單擊后退或前進(jìn))，應(yīng)用程序都可以使用該功能采取適當(dāng)?shù)拇胧?應(yīng)用程序可以跟蹤它自己的歷史記錄，我應(yīng)該能夠在應(yīng)用程序中顯示歷史記錄按鈕(尤其是對(duì)于 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).

據(jù)我所知，這可以跨瀏覽器工作，并且在內(nèi)存或處理器資源方面沒有成本.所以我的問題是:這是否是管理 XHR 應(yīng)用程序歷史的可行解決方案?有什么好處和壞處?

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?

更新:因?yàn)槲沂褂米灾瓶蚣埽也幌胧褂矛F(xiàn)有框架之一.為了能夠在 IE 中使用 location.hash 并將其保存在歷史記錄中，我創(chuàng)建了一個(gè)簡單的腳本(是的，它需要一個(gè) iframe)，它可能對(duì)您有用.我在我的網(wǎng)站發(fā)布了它，請(qǐng)隨意使用/修改/批評(píng)它.

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.

推薦答案

我認(rèn)為您將很難知道用戶是前進(jìn)還是后退.假設(shè) url 開始/myapp#page1 所以你開始跟蹤狀態(tài).然后用戶做一些事情來制作 url/myapp#page2然后用戶做一些事情來再次制作 url/myapp#page1.現(xiàn)在他們的歷史是模棱兩可的，你不知道要?jiǎng)h除什么.

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.

另一個(gè)缺點(diǎn)是用戶總是會(huì)先選擇瀏覽器的后退按鈕，然后再選擇您的自定義后退按鈕.我感覺每 250 毫秒讀取一次歷史記錄的延遲也會(huì)很明顯.也許您可以將間隔做得更緊，但我不知道這是否會(huì)使事情表現(xiàn)不佳.

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)中并不是一直都能完美運(yùn)行，但它已經(jīng)被很多用戶和開發(fā)者使用.他們使用的模式也非常靈活.

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.

這篇關(guān)于監(jiān)控 location.hash 是 XHR 應(yīng)用中歷史的解決方案嗎?的文章就介紹到這了，希望我們推薦的答案對(duì)大家有所幫助，也希望大家多多支持html5模板網(wǎng)！