Comments 42
setTimeout конечно напрягает немного, а так все здорово конечно.
Не забываем, что каждая запись в localStorage — физическое обращение к диску)
Так, жесткий диск Василия Пупкина был убит в износ неизвестным хакером из России…
RubtsovAV подсказал, что можно сравнивать текущее значение хранилища и сериализованного объекта, а затем уже сохранять.
Устроим ад SSDшникам :)
Можно добавить проверку в _save перед сохранением на предмет: а были собсно изменения с последнего сохранения? В остальном оч интересное решение, нужно брать на вооружение. Спасибо!
В таймере забыли сохранить sessionStorage
Таймер не остановится если в коде потеряется ссылка на экземпляр ObjectStorage. Может вместо плоского типа сделать что-то вроде менеджера?
Подробнее, что вы имеете в виду?
function someTest() {
// ...
// Здесь в конструкторе ObjectStorage создался таймер -->
var storage = new ObjectStorage("someStorage");
// ...
// Функция закончила своё действие, ссылка на storage
// потеряна, а таймер живёт, да и сборщик мусора объект
// не убьет
}
function someTest2() {
// ...
// То же самое, что и в someTest
var storage = new ObjectStorage("someStorage");
// ...
}
someTest();
someTest2();
В итоге после вызова someTest и someTest2 будут крутится два потерянных таймера. И так каждый раз при создании экземпляра ObjectStorage.
Первое предложение я понял, а вот второе нет («Может вместо плоского типа сделать что-то вроде менеджера?»).
Какое решение этой проблемы вы предложите? Что-то типа синглтона?
Какое решение этой проблемы вы предложите? Что-то типа синглтона?
Честно говоря, не вижу никакого смысла. В моём варианте человек может создать два экземпляра конструктора с разными именами и интервалами. Во-первых это позволит сохранять реже или чаще те или иные данные, в зависимости от «важности», во вторых не придется каждый раз сериализовывать всё, когда можно это делать по кускам.
По поводу того, что в разных экземплярах будет перезаписываться один и тот же ключ хранилища, согласен.
А как быть с «убийством» интервала, когда ссылка не объект утеряна? Я вижу только один вариант: сделать какой-нибудь метод, который убивает интервал.
По поводу того, что в разных экземплярах будет перезаписываться один и тот же ключ хранилища, согласен.
А как быть с «убийством» интервала, когда ссылка не объект утеряна? Я вижу только один вариант: сделать какой-нибудь метод, который убивает интервал.
можно класть по unload, надежнее
Используйте геттеры и сеттеры вместо таймаута
И спойлер обязательно впихнули).
А в Opera Mobile setTimeout работает?
И кто-то «каждые несколько миллисекунд» — тестировал на большом объёме данных? Когда локал сторадж забит на все свои 5 Мб?
И кто-то «каждые несколько миллисекунд» — тестировал на большом объёме данных? Когда локал сторадж забит на все свои 5 Мб?
Насчет Timeout не скажу, а вот про «милисекунды» — сложно представить случай, когда нужно так часто сохранять данные. По мне интервал в 1-5 секунд самый оптимальный для таких задач.
При больших объемах можно отключать таймаут и делать сохранение, только в нужных местах. Можно добавить условие, что если duration === false, то таймер не запускать.
p.s. даже лучше вот так пожалуй if(duration > 0) setTimeout(....)
p.s. даже лучше вот так пожалуй if(duration > 0) setTimeout(....)
В принципе, гораздо проще так:
А потом так:
localStorage.setup = function(obj){
for(var i in obj){
if(Object.prototype.hasOwnProperty.call(obj, i))
localStorage.setItem(i, obj[i]);
}
}
А потом так:
localStorage.setup({ a:10, b:20 });
Цель данного — объяснить всем тем, кто добавил статью по ссылке в избранное или поставил плюсик, никогда не использовать этот код.
И где же собственно разоблачение?
Возможно ваш код лучше, но чем тот код аж так плох?
И где же собственно разоблачение?
Возможно ваш код лучше, но чем тот код аж так плох?
Sign up to leave a comment.
Работа с локальным хранилищем, как с объектом — Продолжение