Ajax局部页面刷新和History API结合的陷阱
|
ajax在现代网站已经得到非常普遍地应用，主要的好处大家都知道（异步加载数据，不用刷新整个浏览器，更小的数据传输尺寸）。对于那些老网站或者老项目来说全盘改造成ajax并不现实，于是就有了“局部页面刷新”这个解决方案。如果不知道“局部页面刷新”是何物请看这里，这里和这里。 在我们的项目里，将原来的 于是乎原来老旧的网站变成了一个时髦的基于ajax的网站，每个页面传输的数据量变小了，再也不用解决令人头疼的:
因为大家永远都在同一个window里，而且div本身就会根据内容自动撑大。但是等等！浏览器怎么不能后退了？ 我们的那个项目是一个满大街可见的XX管理信息系统，这种系统最常见的布局就是左侧一个树形菜单区域，右侧是一个功能区域，功能区域里有一个查询条件区域（里面有个查询按钮），还有一个空白的区域用来显示查询结果，同时是用户操作数据的地方（比如form表单）。 在iframe时代，上面讲到的4个区域都是一个iframe，这也就意味着我们可以有很变态的后退能力。 但是在引入了ajax后无法后退了，因为ajax请求不会记录到浏览器历史里，历史都没有了自然就无法后退了。 好在Html5的History API能够帮助我们解决问题。我们可以人为的使用 但是事情远不止这么简单，下面是我们遇到的一些坑： 陷阱1：重复执行js脚本// 点击查询按钮的时候人为构造一个浏览器历史
$('#some-button').click(function() {
$(targetSelector).load(url);
history.pushState({
container : targetSelector,content : $(targetSelector).html()
},null,url);
});
// 当浏览器后退后者前进的时候，我们把当时的结果重新加载到container里来
window.addEventListener('popstate',function() {
var state = history.state
$(state.container).html(state.content);
})
一切看上去都OK，直到...我们发现局部页面刷新所获得的结果里包含了操作dom元素的js。 当遇到这种情况时会发生很奇妙的现象，history state.content是已经加载完毕+js执行后的结果，当我们重新还原的时候，我们会把这个结果加载出来，并且又会执行一遍js。如果这个js是一个添加dom的动作那么在后退的时候你会看到这个重复的dom元素。 我们想过跟踪哪些dom元素是被js修改过的来避免这个问题，但是...这是不现实的。 陷阱2：无法还原到最初状态前面的方案因为load的内容里可能有js脚本所以有严重缺陷，于是我们换了个思路，history里保存responseText，而不是已经load好后的东西。 // 点击查询按钮的时候人为构造一个浏览器历史
$('#some-button').click(function() {
$(targetSelector).load(url,function(responseText) {
history.pushState({
container : targetSelector,content : responseText
},url);
});
});
// popstate事件的处理方式一样
但是仍然遇到了这么一个问题，如果container（刷新目标区域，某个div）原来是有内容的，而这个内容不是通过ajax局部页面刷新而来，而是用户一进入这个页面就已经有的，比如使用服务器端的模板引擎生成的页面，那么在它加载完html片段后就无法回退了。因为它的内容一开始就不在history里（事实上浏览器自己产生的history是没有state的），这样就形成了退无可退的局面。 如果你想，我们只要保存这个container原来的内容不就行了，当后退的时候我们直接恢复它原来的内容，但是请看陷阱1 不过当发生退无可退的情况时，我们认为已经退回到了第一次进入页面的状态，这个时候我们刷新整个页面就行了。 陷阱3：多个并列的container陷阱2的解决方案实际上是基于container之间是属于嵌套关系或者就一个container的情况的。如果是这种情况就不行了： 有A和B两个container，点击某个按钮刷新了A的内容（产生历史），然后在点击某个按钮刷新的B的按钮（产生历史），按照用户的预想情况，第一次后退还原B原来的内容，第二次后退还原A原来的内容。但实际上，第一次后退无法还原B的内容（陷阱2），第二次后退页面刷新了（一切恢复最初的样子）。 如果B是嵌套在A里的就无所谓了，第一次后退的时候获得的是A的state，根据A的state还原A的内容的时候顺便把B也还原了，第二次后退页面刷新，把A也还原了。 而且根据陷阱1所讲，我们也不能在history里存储A或者B里原来的内容。 解决办法：对于这种操作就不要记录历史了。 陷阱4：看到过时页面我们在History state里存的是当时load时的responseText，当我们后退的时候看到的是过时的页面，比如我们原先查询结果里看到有A记录，然后我们跳转到其他页面里，然后再后退到查询结果页面看到A记录还在，但是这个A记录很可能只是一个幽灵，在数据库里早就已经不存在了。如果我们这个时候再对A记录操作就有出现错误。 解决办法是我们在history state里保存url已经相关的参数，当popstate的时候重新发起请求就行了，这样一来的话也减少了history存储state所需要的空间。 // 这里只给get请求的例子，post的原理也差不多
$('#some-button').click(function() {
$(targetSelector).load(url,url : url
},url);
});
});
window.addEventListener('popstate',function() {
var state = history.state;
$(state.container).load(state.url);
});
陷阱5：redirect即使我们在history state保存了url你就以为没事了？too simple,too naive！如果我们对这个url发起的请求被服务器redirect到另一个url，那么在history state里保存这个url就不对了。 如果我们这个url是用来删除某条记录的，服务器收到请求在数据库里删除了这条记录，然后redirect到了首页url，那么这个时候你在history里应该存那个url呢？显然是首页的url，因为如果你存了删除url，那么在后退的时候，我们会重新发起这个url，想想这多吓人。 解决办法其实不太简单，因为ajax是否被redirect你是不知道的，用jQuery封装的jqXHR对象也没法知道这个。 也许链WHATWG的XmlHttpRequest.responseURL可以救你，但是浏览器兼容性不好。 我的做法在服务器 陷阱6：无法精确还原dom对象的状态不论是保存responseText还是保存url请求参数，都无法在浏览器后退的时候精确还原dom对象的状态，比如我在IE6里有个这样的特性，你在某个页面勾选了某个checkbox，然后跳转到一个新的页面然后再后退，那个checkbox还是处于勾选状态，这个在利用ajax局部页面刷新里是完全做不到的，想到用户和我说以前后退的时候那个勾还在现在勾没有了，不解决这个BUG就不验收的事情时才想到iframe的好啊。 所以如果要精确还原dom对象的状态，得在history.pushState的时候自行把相关信息保存下来，在popstate的时候用到这些信息并还原dom。 事实上即使用了iframe也并不是所有的浏览器会还原dom对象状态，看这篇文章。 总结
参考资料
（编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |