在localStorage中存储变量太慢 [英] storing a variable in localStorage is too slow

查看:142
本文介绍了在localStorage中存储变量太慢的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有两个jQuery移动页面(#list和#show)。 #list页面上有几个不同ID的项目。如果我点击item no.5,ID no5将被存储在localStorage中,我将被重定向到页面#show



现在问题:
存储localStorage中的ID有效,但下一页显示的不是第5项,但它显示了一个旧项目,它位于localStorage之前。



脚本从页面#list

  localStorage.setItem(garageID,$(this).attr( 'ID')); 
window.location.replace(#show);


解决方案

我也遇到过这个问题:在Chromium / linux上)。

由于似乎没有基于回调的API,我用一个阻止页面的超时固定在 setItem 操作完成之前关闭:

  localStorage.setItem名称,价值); 
setTimeout(function(){
//改变位置
},50);

超时 0 可能就够了,但因为我没有找到任何规范(这可能是在bug的领域),并且问题没有被一贯地转载,我没有任何机会。如果你想要,你可以在一个循环中测试:
$ b $ pre $ function setLocalStorageAndLeave(name,value,newLocation){
value = value.toString(); //防止无限循环
localStorage.setItem(name,value);
(函数one(){
if(localStorage.getItem(name)=== value){
window.location = newLocation;
} else {
setTimeout (一,30);
}
})();
}

但我不明白 localStorage.getItem 返回正确的值将保证它的确是以永久的方式写的,因为没有可中断行为的规范,我不知道是否规范的以下部分可以合法地解释为:允许浏览器在离开磁盘时忘记在磁盘上进行转储页面:


本规范不要求上述方法等到
数据被物理写入磁盘。只需要在访问相同的键/值
对的底层列表的
不同脚本中看到一致性。


在您的具体情况中,解决方案可能是简单地滚动到具有该名称的元素,以避免更改页面。



关于假定错误的注意事项:



我没有找到也没有填写任何错误报告,因为我发现很难重现。在Chromium / linux上观察的情况下,它发生在 delete 操作中。


I have two jQuery mobile pages (#list and #show). There are several items on the #list page with different IDs. If I click on item no.5, the ID no5 will be stored in localStorage and I will be redirected to page #show

Now the problem: Storing the ID in localStorage works, but the next page shows me not the item no.5, but it shows me an old item, that was in the localStorage before.

script from page #list

localStorage.setItem("garageID", $(this).attr('id'));                           
window.location.replace("#show");

解决方案

I encountered this problem too (and not on a mobile : on Chromium/linux).

As there doesn't seem to be a callback based API, I "fixed" it with a timeout which "prevents" the page to be closed before the setItem action is done :

localStorage.setItem(name, value);                           
setTimeout(function(){
     // change location
}, 50);

A timeout of 0 might be enough but as I didn't find any specification (it's probably in the realm of bugs) and the problem isn't consistently reproduced I didn't take any chance. If you want you might test in a loop :

function setLocalStorageAndLeave(name, value, newLocation){
    value = value.toString(); // to prevent infinite loops
    localStorage.setItem(name, value);
    (function one(){
         if (localStorage.getItem(name) === value) {
            window.location = newLocation;
         } else {
            setTimeout(one, 30);
         }
    })();
}

But I don't see how the fact that localStorage.getItem returns the right value would guarantee it's really written in a permanent way as there's no specification of the interruptable behavior, I don't know if the following part of the spec can be legitimately interpreted as meaning the browser is allowed to forget about dumping on disk when it leaves the page :

This specification does not require that the above methods wait until the data has been physically written to disk. Only consistency in what different scripts accessing the same underlying list of key/value pairs see is required.

In your precise case, a solution might be to simply scroll to the element with that given name to avoid changing page.

Note on the presumed bug :

I didn't find nor fill any bug report as I find it hard to reproduce. In the cases I observed on Chromium/linux it happened with the delete operation.

这篇关于在localStorage中存储变量太慢的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆