Локальное хранилище. HTML5 локальное хранилище данных на стороне клиента. Базовые CRUD-операции с куки

Привет всем! В этой статье мы разберем, что такое localStorage и как его использовать .

Введение

LocalStorage - локальное хранилище. Т.е. это специально отведенное место в браузере(что-то вроде небольшой базы данных), где мы можем записывать, читать и удалять какие-то данные. На самом деле, локальное хранилище очень похоже на COOKIE , но есть отличия. Вот давайте о них и поговорим. Cookie очень ограничены. В одной cookie может быть всего 4096 символов, а их количество на один домен примерно 30-50 в зависимости от браузера. В локальном хранилище мы можем хранить 5-10мб или даже больше на длительное время.

Где их использовать

Самое большое отличие cookie от localStorage - это то, что первый работает с сервером, а второй нет, хотя это тоже можно сделать, но об этом немного позже. Используйте локальное хранилище там, где вам не нужна тесная работа с сервером, а нужно хранить какие-то временные данные. К примеру, представим, что вы создаете какое-то web-приложение, куда человек может зайти, ввести несколько задач, которые он хочет сделать за день и удалить те, которые уже выполнил. Зачем нам тут сервер? Правильно, не за чем. Вот тут и стоит использовать localStorage . Человек заходит, вводит задачи, они записываются в специальное место его браузера и там хранятся. Когда человек зайдет снова через какое-то время, они будут оттуда выбраны и показаны. К примеру, кликнув по задаче, она будет удаляться с локального хранилища и, следовательно, показываться ему уже не будет. Перейдем к тому, как его использовать.

Как использовать localStorage

Хранятся данные также, как и в cookie - ключ:значение . Чтобы добавить новое значение, напишите так:

LocalStorage.setItem("ключ", "значение");

Мы используем объект localStorage и его метод setItem , куда передаем ключ и значение.

Чтобы получить данные, пишем следующее:

Var value = localStorage.getItem("ключ");

В результате, в переменную value попадет значение, которое хранится под ключом, который мы передаем в метод getItem .

Удаляем данные

LocalStorage("ключ"); // удалит данные под переданным ключом
localStorage.clear(); // полностью очистит локальное хранилище

Чтобы проверить, не переполнено ли локальное хранилище, вы можете использовать константу QUOTA_EXCEEDED_ERR

Try {
localStorage.setItem("ключ", "значение");
} catch (e) {
if (e == QUOTA_EXCEEDED_ERR) {
alert("Превышен лимит");
}
}

Вот и все, что следует знать про localStorage . Стоит сказать, что помимо этого объекта есть еще один - sessionStorage . Отличается он только тем, что хранит данные только для одной вкладки, и они будут удалены, как только пользователь закроет вкладку.

В начале статьи я говорил, что локальное хранилище создано для того, чтобы хранить локальные данные и не общаться с сервером, но, однако, такая возможность у нас все же есть. Думаю, некоторые уже могли догадаться, как это сделать. Итак, если вам нужно отправить какие-то данные на сервер, то сделайте следующее: получите данные из локального хранилища, преобразуйте их в JSON строку и отправьте с помощью технологии Ajax . Так же можно их и принимать от сервера.

Итог

Итак, используйте localStorage там, где вам не нужно общаться с сервером, а нужно хранить данные локально, в браузере у пользователя. Все, что вам для этого нужно, мы рассмотрели в этой статье. Спасибо за внимание и до скорого!

Перевод: Влад Мержевич

Постоянное локальное хранилище это одна из областей, где клиентские приложения имеют преимущества перед серверными. Для приложений, таких как операционная система, обеспечивается уровень абстракции для хранения и извлечения данных вроде настроек или статуса выполнения. Эти значения могут быть сохранены в реестре, INI-файлах, XML-файлах или в другом месте в зависимости от принципов платформы. Если ваше клиентское приложение нуждается в локальном хранилище больше чем просто пара ключ/значение, вы можете вставить свою собственную базу данных, придумать свой формат файлов или любое количество других решений.

Исторически, у веб-приложений не было ни одной из этих роскошей. Кукисы были изобретены в начале истории Интернета и они могут быть использованы для постоянного локального хранения небольших объемов данных. Но у них есть три потенциальных минуса:

• кукисы включаются в каждый HTTP-запрос, замедляя тем самым ваше веб-приложение на напрасную передачу одних и тех же данных снова и снова;
• кукисы включаются в каждый HTTP-запрос при передаче данных через Интернет в незашифрованном виде (даже если все веб-приложение передается через SSL);
• кукисы ограничены объемом данных примерно 4 Кб - достаточно, чтобы замедлить ваше приложение (см. выше), но не достаточно, чтобы быть полезным.

Вот что мы действительно хотим:

• много места для хранения;
• работа на стороне клиента;
• учитывать обновление страницы;
• нет отправки на сервер.

Перед HTML5 все попытки добиться этого в конечном итоге были по-разному провальными.

Краткая история локального хранилища до HTML5

Вначале был только один Internet Explorer. По крайней мере, Майкрософт хотел, чтобы мир так думал. С этой целью в рамках Первой Великой Войны браузеров Майкрософт изобрел очень много вещей и включил их в свой браузер-который-завершил-войну - Internet Explorer. Одна из этих вещей была названа DHTML Behaviors , а одна из форм поведения называется userData .

UserData позволяет веб-странице хранить до 64 Кб данных на каждый домен в иерархической XML-подобной структуре. Доверенные домены, такие как интранет-сайты могут хранить в десять раз больше. И эй, 640 Кб должно быть достаточно для всех. IE не представил какой-либо способ изменить эти соглашения, поэтому нет способа увеличить объем доступной памяти.

В 2002 году компания Adobe представила функцию во Flash 6, которая получилась неудачной и с названием, вводящим в заблуждение - «Flash-кукисы». В среде Flash эта возможность известна более правильно как Local Shared Objects (локальные доступные объекты, LSO). Вкратце, она позволяет Flash-объектам хранить до 100 Кб данных на каждый домен. Брэд Нойберг разработавший ранний прототип моста между Flash и JavaScript назвал ее AMASS (AJAX Massive Storage System), но она была ограничена некоторыми причудами Flash-дизайна. К 2006 году с появлением ExternalInterface во Flash 8 доступ к LSO через JavaScript стал на порядок проще и быстрее. Брэд переписал AMASS и интегрировал ее в популярный Dojo Toolkit под псевдонимом dojox.storage . Flash «бесплатно» дает каждому домену 100 кб для хранения. Кроме того, он предлагает пользователю при запросе увеличивать объем хранения на порядок (1 Мб, 10 Мб и т.д.).

if (Modernizr.localstorage) {
// window.localStorage is available!
} else {
// нет встроенной поддержки HTML5-хранилища
}

Использование HTML5-хранилища

HTML5-хранилище базируется на именах пар ключ/значение. Вы сохраняете информацию, основываясь на имени ключа, а затем можете получить эти данные с тем же ключом. Имя ключа это строка. Данные могут быть любого типа, который поддерживает JavaScript, включая строки, логические, целые числа или числа с плавающей запятой. Однако в действительности данные хранятся в виде строки. Если вы сохраняете и извлекаете не строки, то надо будет использовать такие функции как parseInt() или parseFloat() , чтобы перевести полученные данные в корректные типы JavaScript.

Интерфейс хранилища {
Получить через getItem(ключ);
Установить через setItem(ключ, данные);
};

Вызов setItem() с существующим именем ключа молча перепишет предыдущее значение. Вызов getItem() с несуществующим ключом вернет NULL, а не вызовет исключение.

Подобно другим объектам JavaScript вы можете обращаться к объекту localStorage как к ассоциативному массиву. Вместо использования методов getItem() и setItem() , вы можете просто указать квадратные скобки. Например, этот фрагмент кода

var foo = localStorage.getItem("bar");
// ...
localStorage.setItem("bar", foo);

может быть переписан с использованием синтаксиса квадратных скобок:

var foo = localStorage["bar"];
// ...
localStorage["bar"] = foo;

Есть также методы для удаления значений по имени ключа, а также очистки всего хранилища (то есть удаление всех ключей и значений одновременно).

Интерфейс хранилища {
Удалить через removeItem(ключ);
clear();
}

Вызов removeItem() с несуществующим ключом ничего не вернет.

Наконец, есть свойство для получения общего количества значений в области хранения и для перебора всех ключей по индексу (получает имя каждого ключа).

Интерфейс хранилища {
length
Получить key(целое неотрицательное число);
}

Если при вызове key() индекс лежит не в диапазоне от 0 до (length-1), то функция вернет null .

Слежение за областью HTML5-хранилища

Если вы хотите программно отслеживать изменения хранилища, то должны отлавливать событие storage . Это событие возникает в объекте window , когда setItem() , removeItem() или clear() вызываются и что-то изменяют. Например, если вы установили существующее значение или вызвали clear() когда нет ключей, то событие не сработает, потому что область хранения на самом деле не изменилась.

Событие storage поддерживается везде, где работает объект localStorage , включая Internet Explorer 8. IE 8 не поддерживает стандарт W3C addEventListener (хотя он, наконец-то, будет добавлен в IE 9), поэтому, чтобы отловить событие storage нужно проверить, какой механизм событий поддерживает браузер (если вы уже проделывали это раньше с другими событиями, то можете пропустить этот раздел до конца). Перехват события storage работает так же, как и перехват других событий. Если вы предпочитаете использовать jQuery или какую-либо другую библиотеку JavaScript для регистрации обработчиков событий, то можете проделать это и со storage тоже.

if (window.addEventListener) {
window.addEventListener("storage", handle_storage, false);
} else {
window.attachEvent("onstorage", handle_storage);
};

Функция обратного вызова handle_storage будет вызвана с объектом StorageEvent , за исключением Internet Explorer, где события хранятся в window.event .

function handle_storage(e) {
if (!e) { e = window.event; }
}

В данном случае переменная e будет объектом StorageEvent , который обладает следующими полезными свойствами.

* Примечание: свойство url изначально называлось uri и некоторые браузеры поддерживали это свойство перед изменением спецификации. Для обеспечения максимальной совместимости вы должны проверить существует ли свойство url , и если нет проверить вместо него свойство uri .

Событие storage нельзя отменить, внутри функции обратного вызова handle_storage нет возможности остановить изменение. Это просто способ браузеру сказать вам: «Эй, это только что случилось. Вы ничего не можете сделать, я просто хотел, чтобы вы знали».

Ограничения в текущих браузерах

Говоря об истории локального хранилища с помощью сторонних плагинов, я упомянул про ограничения каждой техники. Я вспомнил, что не сказал ничего об ограничениях теперь уже стандартного HTML5-хранилища. Я дам вам ответы, а затем объясню их. Ответы в порядке важности такие: «5 мегабайт», «QUOTA_EXCEEDED_ERR» и «нет».

«5 мегабайт» - сколько места для хранения выдается по умолчанию. Это значение на удивление одинаково во всех браузерах, хотя и сформулировано не более как предложение в спецификации HTML5. Надо понимать, что вы храните строки, а не данные в исходном формате. Если вы храните много целых чисел или чисел с плавающей запятой, разница в представлении может оказаться большой. Каждая цифра в числе с плавающей запятой хранится в виде символа, а не в обычном представлении для таких чисел.

«QUOTA_EXCEEDED_ERR» это исключение, которое вы получите, если превысите свою квоту в 5 Мб. «Нет» является ответом на следующий очевидный вопрос: «Могу ли я попросить у пользователя больше пространства для хранения?». На момент написания в браузерах не реализован какой-либо механизм для веб-разработчиков, чтобы запросить больше места для хранения. Некоторые браузеры (например, Opera) позволяют пользователю контролировать квоты хранилища для каждого сайта, но это чисто инициатива пользователя, не связанная с тем, что вы как разработчик можете встроить в ваше веб-приложение.

HTML5-хранилище в действии

Давайте посмотрим на HTML5-хранилище в действии. Снова обратимся к , которую мы построили в главе про рисование. С этой игрой связана небольшая проблема: если вы закроете окно браузера посередине игры, то потеряете результаты. Но с HTML5-хранилищем мы можем сохранять процесс игры на месте, в самом браузере. Откройте демонстрацию, сделайте несколько ходов, закройте вкладку браузера, а затем снова ее откройте. Если ваш браузер поддерживает HTML5-хранилище, демонстрационная страница волшебным образом вспомнит точное положение в игре, в том числе, сколько ходов вы сделали, положение каждой фишки на доске и даже выбранную фишку.

Как это работает? Каждый раз, когда происходит изменение в игре, мы будем вызывать эту функцию.

function saveGameState() {

localStorage["halma.game.in.progress"] = gGameInProgress;
for (var i = 0; i < kNumPieces; i++) {
localStorage["halma.piece." + i + ".row"] = gPieces[i].row;
localStorage["halma.piece." + i + ".column"] = gPieces[i].column;
}
localStorage["halma.selectedpiece"] = gSelectedPieceIndex;
localStorage["halma.selectedpiecehasmoved"] = gSelectedPieceHasMoved;
localStorage["halma.movecount"] = gMoveCount;
return true;
}

Как видите, используется объект localStorage для сохранения процесса игры (gGameInProgress , логический тип). Далее перебираются все фишки (gPieces , массив JavaScript) и сохраняется строка и столбец для каждой из них. После чего сохраняются некоторые дополнительные состояния игры, включая выбранную фишку (gSelectedPieceIndex , целое число), фишку, которая находится в середине длинной серии прыжков (gSelectedPieceHasMoved , логический тип) и общее число сделанных ходов (gMoveCount , целое число).

При загрузке страницы вместо автоматического вызова функции newGame() , которая бы вернула все переменные в исходные значения, мы вызываем resumeGame() . Функция resumeGame() с помощью HTML5-хранилища проверяет состояние игры в локальном хранилище. Если оно есть, то восстанавливает значения с использованием объекта localStorage .

function resumeGame() {
if (!supportsLocalStorage()) { return false; }
gGameInProgress = (localStorage["halma.game.in.progress"] == "true");
if (!gGameInProgress) { return false; }
gPieces = new Array(kNumPieces);
for (var i = 0; i < kNumPieces; i++) {
var row = parseInt(localStorage["halma.piece." + i + ".row"]);
var column = parseInt(localStorage["halma.piece." + i + ".column"]);
gPieces[i] = new Cell(row, column);
}
gNumPieces = kNumPieces;
gSelectedPieceIndex = parseInt(localStorage["halma.selectedpiece"]);
gSelectedPieceHasMoved = localStorage["halma.selectedpiecehasmoved"] == "true";
gMoveCount = parseInt(localStorage["halma.movecount"]);
drawBoard();
return true;
}

Наиболее важной частью этой функции является оговорка, о которой я упоминал ранее в этой главе и повторю здесь: данные хранятся в виде строк. Если вы храните нечто другое, а не строки, вам нужно конвертировать их при получении. К примеру, флаг о том, что игра в процессе (gGameInProgress ) является логическим типом. В функции saveGameState() мы просто храним его и не беспокоимся о типе данных.

localStorage["halma.game.in.progress"] = gGameInProgress;

Но в функции resumeGame() мы должны рассмотреть значение, полученное из локального хранилища в виде строки и вручную построить собственное логическое значение.

gGameInProgress = (localStorage["halma.game.in.progress"] == "true");

Аналогичным образом, число ходов хранится в gMoveCount как целое, в функции saveGameState() мы просто сохраняем его.

localStorage["halma.movecount"] = gMoveCount;

Но в функции resumeGame() мы должны конвертировать значение в целое, используя встроенную в JavaScript функцию parseInt() .

gMoveCount = parseInt(localStorage["halma.movecount"]);

За пределами пары ключ/значение: конкурентное видение

Хотя в истории было много уловок и обходных путей, нынешнее состояние HTML5-хранилища на удивление благополучно. Новый API был стандартизирован и включен во все основные браузеры, платформы и устройства. Для веб-разработчика такое увидишь не каждый день, не так ли? Но это больше, чем «5 мегабайт пар ключ/значение» и будущее постоянного локального хранилища это... как бы сказать... ну, пусть конкурентное видение.

Одно видение является аббревиатурой, которую вы уже знаете - SQL. В 2007 году Google запустил Gears, кроссбраузерный плагин с открытым исходным кодом, в который включена встроенная база данных на основе SQLite. Этот ранний прототип позже повлиял на создание спецификации Web SQL Database . База данных Web SQL (ранее известная как «WebDB») обеспечивает тонкую оболочку вокруг базы данных SQL, что позволяет делать следующие вещи из JavaScript:

openDatabase("documents", "1.0", "Local document storage", 5*1024*1024, function (db) {
db.changeVersion("", "1.0", function (t) {
t.executeSql("CREATE TABLE docids (id, name)");
}, error);
});

Как вы можете видеть, большая часть действий находится в строке с методом ExecuteSQL. Эта строка может поддерживать любые команды SQL, в том числе SELECT, UPDATE, INSERT и DELETE. Это все равно, что серверное программирования баз данных, за исключением того, что вы делаете это с JavaScript! О радость!

Спецификация базы данных Web SQL была реализована в четырех браузерах и платформах.

Поддержка базы данных Web SQL

IE	Firefox	Safari	Chrome	Opera	iPhone	Android
–	–	4.0+	4.0+	10.5+	3.0+	2.0+

Конечно, если вы использовали более чем одну базу данных в своей жизни, то знаете, что «SQL» это скорее маркетинговый термин, чем жесткий и быстрый стандарт (кто-то может сказать то же самое об HTML5, но это не важно). Конечно, есть актуальная спецификация SQL (она называется SQL-92), но в мире нет сервера баз данных, который соответствует только этой спецификации. Есть Oracle SQL, Microsoft SQL, SQL в MySQL, SQL в PostgreSQL, SQL в SQLite. В действительности, каждый из этих продуктов с течением времени добавляет новые функции SQL, так что недостаточно даже произнести «SQL в SQLite». Вы должны сказать «версия SQL, который поставляется вместе с SQLite версии X.Y.Z».

Все это подводит нас к следующей оговорке, в настоящее время размещенной вверху спецификации Web SQL.

Спецификация зашла в тупик: все заинтересованные разработчики используют серверный SQL (SQLite), но нам нужно несколько независимых реализаций, чтобы двигаться по пути стандартизации. Пока другие разработчики заинтересованы в реализации этой спецификации, описание диалекта SQL было оставлено как обычная ссылка на Sqlite, который не приемлем для стандарта.

Именно на этом фоне я расскажу вам о другом конкурентном видении для продвинутых, постоянное локальное хранилище для веб-приложений: Indexed Database API , ранее известное как «WebSimpleDB», теперь ласково называемое IndexedDB.

Indexed Database API предоставляет то, что называется хранилище объектов, при этом много идей заимствовано из баз данных SQL. Есть «базы данных» с «записями», каждая запись имеет определенное количество «полей». У каждого поля есть определенный тип данных, который определяется при создании базы данных. Вы можете выбрать часть записей, затем перечислить их «курсором». Изменения в хранилище объектов обрабатываются с «транзакциями».

Если вы хоть раз программировали базы данных SQL, то эти термины, вероятно, вам знакомы. Основная разница в том, что хранилище объектов не имеет структурированного языка запросов. Вы не напишите условие вроде "SELECT * from USERS where ACTIVE = "Y"". Вместо этого используются методы, предоставляемые хранилищем объектов для открытия базы USERS, перечисления записей, фильтрации наших записей и использование методов доступа для получения значения каждого поля оставшихся записей. An early walk-through of IndexedDB (Ранний проход IndexedDB) это хорошее руководство о том, как работает IndexedDB и сравнение IndexedDB с Web SQL.

На момент написания IndexedDB был реализован только в бета-версии Firefox 4. Для контраста, Mozilla заявила, что никогда не будет воплощать Web SQL. Google заявил, что они рассматривают поддержку IndexedDB для Chromium и Google Chrome. И даже Майкрософт заявил, что IndexedDB «отличное решение для веб».

Что вы как веб-разработчик можете делать с IndexedDB? На данный момент практически ничего, кроме некоторых технологических демонстраций. Через год? Возможно.

The Web Storage API provides mechanisms by which browsers can store key/value pairs, in a much more intuitive fashion than using cookies .

Web Storage concepts and usage

The two mechanisms within Web Storage are as follows:

• sessionStorage maintains a separate storage area for each given origin that"s available for the duration of the page session (as long as the browser is open, including page reloads and restores)
  • Stores data only for a session, meaning that the data is stored until the browser (or tab) is closed.
  • Data is never transferred to the server.
  • Storage limit is larger than a cookie (at most 5MB).
• localStorage does the same thing, but persists even when the browser is closed and reopened.
  • Stores data with no expiration date, and gets cleared only through JavaScript, or clearing the Browser cache / Locally Stored Data.
  • Storage limit is the maximum amongst the three.

Specifications

Specification	Status	Comment
HTML Living Standard	Living Standard

Browser compatibility

Window.localStorage

https://github.com/mdn/browser-compat-data and send us a pull request.

	Desktop						Mobile
	Chrome	Edge	Firefox	Internet Explorer	Opera	Safari	Android webview	Chrome for Android	Firefox for Android	Opera for Android	Safari on iOS	Samsung Internet
localStorage	Chrome Full support 4	Edge Full support 12	Firefox Full support 3.5	IE Full support 8	Opera Full support 10.5	Safari Full support 4

Legend

Full support Full support

Window.sessionStorage

The compatibility table on this page is generated from structured data. If you"d like to contribute to the data, please check out https://github.com/mdn/browser-compat-data and send us a pull request.

Update compatibility data on GitHub

	Desktop						Mobile
	Chrome	Edge	Firefox	Internet Explorer	Opera	Safari	Android webview	Chrome for Android	Firefox for Android	Opera for Android	Safari on iOS	Samsung Internet
sessionStorage	Chrome Full support 5	Edge Full support 12	Firefox Full support 2	IE Full support 8	Opera Full support 10.5	Safari Full support 4	WebView Android Full support Yes	Chrome Android Full support Yes	Firefox Android Full support Yes	Opera Android Full support 11	Safari iOS Full support 3.2	Samsung Internet Android Full support Yes

Legend

Full support Full support

Private Browsing / Incognito modes

Most modern browsers support a privacy option called "Incognito", "Private Browsing" or something similar that doesn"t store data like history and cookies. This is fundamentally incompatible with Web Storage for obvious reasons. As such, browser vendors are experimenting with different scenarios for how to deal with this incompatibility.

Most browsers have opted for a strategy where storage APIs are still available and seemingly fully functional, with the one big difference that all stored data is wiped after the browser is closed. For these browsers there are still different interpretations of what should be done with existing stored data (from a regular browsing session). Should it be available to read when in Private mode? Then there are some browsers, most notably Safari, that have opted for a solution where storage is available, but is empty and has a quota of 0 bytes assigned, effectively making it impossible to write data to it.

Developers should be aware of these different implementations and take them into account when developing websites depending on Web Storage APIs. For more information please have a look at this WHATWG blog post that specifically deals with this topic.

Перевод статьи: How to use local storage for JavaScript.
Sara Vieira.

Знакомство с основами программирования языка JavaScript зачастую начинается с создания простейших приложений, таких, к примеру, как электронная записная книжка, используемая нами для записи дел и событий, о которых мы можем забыть. Но подобным приложениям свойственна одна проблема — после перезагрузки страницы, список всех оставленных ранее записей исчезает, то есть приложение возвращается в свое исходное состояние.

Существует очень простой выход из данной ситуации, предусматривающий использование механизма локального хранения localStorage . Благодаря тому, что localStorage позволяет нам сохранять необходимые данные на пользовательском компьютере, упомянутый выше список запланированных дел и событий будет все еще доступен после перезагрузки страницы, кроме того, localStorage является на удивление очень простым способом хранения данных и доступа к ним при необходимости.

Что такое localStorage?

Это механизм локального хранения данных, который является частью технологии Web Storage , предусмотренной HTML5 спецификацией. Имеется два варианта хранения данных, допустимые данной спецификацией:

• Локальное хранение: позволяет сохранять информацию без ограничений по срокам хранения. Именно этот вариант мы и будем использовать, поскольку имеющийся в нашем примере список задач должен храниться постоянно.
• Использование сеансов: обеспечивает сохранность данных лишь на период одного сеанса, то есть после закрытия пользователем вкладки нашего приложения и повторного ее открытия вся необходимая для дальнейшей работы приложения информация будет удалена.

Попросту говоря, все, что делает Web Storage , это хранит данные в форме именованный ключ/значение локально и в отличие от двух других методов, каждый из которых имеет свои недостатки (Сеансовое хранение информации предусматривает использование для этого серверной стороны, к тому же после закрытия сеанса пользователя эта информация удаляется, а cookies хотя и используют для хранения сторону клиента, но не надежны потому, что путем настроек браузера пользователь может отменить их поддержку.) сохраняет данные даже в том случае, если вы закрыли браузер или выключили свой компьютер. (*Я позволил себе несколько изменить и дополнить содержание этого абзаца, поскольку считаю, что в оригинале автор допустил неточности. )

HTML

Если придерживаться нашего примера, в котором мы хотим создать электронный вариант записной книжки, то ниже представлены все необходимые компоненты для ее реализации:

• Поле для ввода новых записей (событий, дел и т.п.).
• Кнопка для подтверждения введенной записи.
• Кнопка для очистки уже созданного списка дел.
• Неупорядоченный список, который будет пополняться элементами в виде новых записей.
• И в заключение, нам нужен блок div в качестве контейнера, содержащего выводимые для пользователя сообщения, такие, допустим, как предупреждение о том, что он забыл ввести значение следующей записи, оставив поле ввода пустым.

В результате наша разметка должна иметь примерно такой вид:

Очистить список

Это вполне стандартный HTML шаблон, который мы можем заполнить динамически формируемым контентом с помощью JavaScript .

JavaScript

Применительно к структуре взятого в нашем примере простейшего приложения блокнота, первое, что нам необходимо сделать, это обеспечить отслеживание события нажатия кнопки «Добавить запись» и проверять, введена ли в текстовое поле для записи какая-нибудь информация, то есть в момент нажатия кнопки оно должно быть не пустым. Что-то на пример вот этого:

$("#add").click(function() {
//если текстовое поле не заполнено
$("#alert").html("Внимание! Введите запись в текстовое
поле.");
return false;
}

Вот что мы делаем с помощью этого фрагмента кода. При нажатии кнопки «Добавить запись» мы проверяем, ввел ли пользователь что-нибудь в поле для новой записи. Если он этого не сделал, то появляется предусмотренный нами для вывода сообщений div , информируя пользователя о том, что поле ввода записи не заполнено и затем, по истечении 1000ms (1 секунда) элемент div , а соответственно и сообщение, исчезает. Далее функция возвращает значение false , после чего браузер прекращает выполнение остальной части скрипта и приложение снова готово к вводу новой записи.

Следующим нашим шагом будет добавление в начало списка введенного в поле для записей значения путем генерации нового элемента списка. Таким образом, когда пользователь дописывает еще одну запись, то она всегда будет помещаться в начало списка намеченных дел и ожидаемых событий. После этого нам остается лишь сохранить список с помощью механизма localStorage :

// Добавляем запись в существующий список
$("#todos").prepend("

" + Description + "

");
// Очищаем поле ввода
$("#form").reset();

return false;
});

Как вы, возможно, заметили, здесь нет ничего необычного, используется стандартный вариант jQuery кода. В месте обращения к объекту localStorage мы должны указать сохраняемые нами данные в форме ключ/значение . Для ключа можно использовать произвольное имя, и я назвал его "todos" , далее нужно указать то, что нам, собственно, необходимо сохранить в памяти. В данном случае это полный фрагмент HTML разметки, включаемый в неупорядоченный список (находящийся между тегами ), с помощью которого отображаются все введенные пользователем ранее записи. Из кода видно, что мы просто извлекаем необходимый нам фрагмент с помощью jQuery метода .html() и в конце, выполнив все необходимые действия, устанавливаем возвратное значение функции в false , что предотвращает отправку данных формы и, следовательно, перезагрузку нашей страницы.

Теперь, допустим, наш пользователь ранее уже внес несколько записей и для дальнейшей нормальной работы приложения нам нужно проверить имеется ли в localStorage сохраненная прежде на компьютере информация и если да, то отобразить ее для пользователя. Поскольку имя нашего ключа "todos" , то мы должны проверить его существование следующим образом:

// если в локальном хранилище уже есть данные, то отображаем их

}

Для проверки наличия данных мы использовали обычный if оператор и при выполнении указанного нами условия, просто извлекли из локального хранилища все данные, поместив их в качестве HTML разметки внутри неупорядоченного списка, с помощью которого отображаются введенные ранее пользователем записи.

Если вы проверите работу своего простейшего приложения, то обнаружите, что после перезагрузки страницы все остается на месте. И теперь, последнее, что нам остается сделать, так это создать функцию, с помощью которой пользователь при необходимости смог бы удалить все свои записи. Это реализуется путем очистки localStorage и перезагрузки страницы для активации сделанных изменений. Далее, мы, как и в предыдущем случае устанавливаем false в качестве возвратного значения функции, что предотвращает появление хэша в URL . (*и не прокручивает страницу вверх. ):

// Полная очиска localStorage
window.localStorage.clear();
location.reload();
return false;
});

В результате имеем полностью функционирующее приложение. И собирая все приведенные выше фрагменты воедино, получаем полный код приложения:

$("#add").click(function() {
var Description = $("#description").val();
if($("#description").val() == "") {
$("#alert").html("Внимание! Введите запись в
текстовое поле.");
$("#alert").fadeIn().delay(1000).fadeOut();
return false;
}
$("#todos").prepend("

"
+ Description + "

");
$("#form").reset();
var todos = $("#todos").html();
localStorage.setItem("todos", todos);
return false;
});

if(localStorage.getItem("todos")) {
$("#todos").html(localStorage.getItem("todos"));
}

$("#clear").click(function() {
window.localStorage.clear();
location.reload();
return false;
});

Поддержка браузеров.

В HTML5 спецификации предусмотрена достаточно мощная поддержка технологии Web Storage , благодаря чему она также реализована большинством популярных браузеров, даже IE8 . Единственной проблемой остается IE7 , если вас это все еще интересует.

Заключение.

В таких небольших приложениях механизм localStorage может вполне успешно заменить использование баз данных. Для хранения небольших объемов данных совсем не обязательно использовать более сложные альтернативы.

* Примечание переводчика.

Post Views: 475

Обзор Web Storage

В интернете информацию можно сохранять в двух местах: на веб-сервере и на веб-клиенте (т.е. компьютере посетителя страницы). Определенные типы данных лучше хранить в одном из этих мест, а другие типы - в другом.

Правильным местом для хранения конфиденциальных и важных данных будет веб-сервер. Например, если вы положите какие-либо товары в свою корзину в онлайновом магазине, данные о вашей потенциальной покупке сохраняются на веб-сервере. На вашем компьютере сохраняется лишь несколько байтов данных для отслеживания, содержащих информацию о вас (или, вернее, о вашем компьютере), чтобы веб-сервер знал, какая из корзин ваша. Даже с новыми возможностями HTML5 изменять эту систему нет надобности - она надежная, безопасная и эффективная.

Но хранение данных на сервере не всегда является лучшим подходом, т.к. иногда легче хранить второстепенную информацию на компьютере пользователя. Например, имеет смысл хранить локально пользовательские настройки (скажем, параметры, которые определяют способ отображения веб-страницы) и состояние приложения (снимок текущего состояния веб-приложения), чтобы посетитель мог продолжить его выполнение с того же самого места позже.

До HTML5 единственным способом локального хранения данных было использование механизма файлов cookies , который первоначально был разработан для обмена небольшими объемами идентифицирующей информации между веб-серверами и браузерами. Файлы cookies подходят идеально для хранения небольших объемов данных, но модель JavaScript для работы с ними несколько неуклюжа. Система файлов cookies также вынуждает разработчика возиться со сроками действия и бесполезно пересылать данные туда и обратно по интернету с каждым запросом страницы.

В HTML5 вводится лучшая альтернатива файлам cookies, которая позволяет легко и просто сохранять информацию на компьютере посетителя. Эта информация может храниться на клиентском компьютере неограниченное время, не отправляется на веб-сервер (если только разработчик не сделает это сам), может быть большого объема и для работы с ней требуется всего лишь пара простых, эффективных объектов JavaScript.

Эта возможность называется веб-хранилищем (Web Storage) и особенно хорошо подходит для применения с автономным режимом работы вебсайтов, т.к. позволяет создавать самодостаточные автономные приложения, которые могут сохранять всю требуемую им информацию даже при отсутствии подключения к интернету.

Функциональность веб-хранилища HTML5 позволяет веб-странице сохранять данные на компьютере посетителя. Эта информация может быть кратковременной, которая удаляется после выключения браузера, или долговременной, которая остается доступной при последующих посещениях веб-страницы.

Сохраняемая в веб-хранилище информация в действительности сохраняется не в интернете, а на компьютере посетителя веб-страницы. Иными, словами, веб-хранилище означает хранение данных не в интернете, а хранение данных из интернета.

Существуют два типа веб-хранилищ, которые так или иначе связаны с двумя объектами:

Локальное хранилище

Использует объект localStorage для хранения данных для всего веб-сайта на постоянной основе. Это означает, что если веб-страница сохранит данные в локальном хранилище, эти данные будут доступны для пользователя, когда он возвратится на эту веб-страницу на следующий день, на следующей неделе или в следующем году.

Конечно же, большинство браузеров также предоставляет пользователю возможность очистить локальное хранилище. В некоторых браузерах она реализована как стратегия "все или ничего", и посредством ее удаляются все локальные данные, во многом подобно тому, как удаляются cookies-файлы. (В действительности, в некоторых браузерах система cookies и локальное хранилище взаимосвязаны, так что единственным способом удалить локальные данные будет удаление cookies.) А другие браузеры могут предоставлять пользователю возможность просмотра данных для каждого отдельного веб-сайта и удалять данные для выбранного сайта или сайтов.

Хранилище данных сеансов

Использует объект sessionStorage для временного хранения данных для одного окна или вкладки браузера. Эти данные доступны лишь до тех пор, пока пользователь не закроет окно или вкладку, после чего сеанс заканчивается и данные удаляются. Но данные сеанса сохраняются, если пользователь переходит на другой веб-сайт, а потом возвращается обратно при условии, что это происходит в том же окне браузера.

С точки зрения кода веб-страницы, как локальное хранилище, так и хранилище данных сеансов работают абсолютно одинаково. Разница состоит лишь в длительности хранения данных.

Использование локального хранилища предоставляет наилучшую возможность для сохранения требуемой информации для последующих посещений вебстраницы пользователем. А хранилище сеансов служит для хранения данных, которые нужно передавать от одной страницы другой. (В хранилище сеансов можно также хранить временные данные, используемые только на одной странице, но для этой цели прекрасно работают обычные переменные JavaScript.)

Как локальное хранилище, так и хранилище сеансов связано с доменом веб-сайта. Таким образом, если сохранить в локальном хранилище данные для страницы www..html, эти данные будут доступны для страницы www..html, т.к. обе эти страницы имеют один и тот же домен. Но эти данные не будут доступны для страниц других доменов.

Кроме этого, т.к. веб-хранилище расположено на компьютере (или мобильном устройстве) данного пользователя, оно связано с этим компьютером, и веб-страница, открытая на данном компьютере и хранящая данные в его локальном хранилище, не имеет доступа к информации, которую она сохранила на другом компьютере. Подобным образом веб-страница создает отдельное локальное хранилище, если вы войдете в систему под другим именем пользователя или запустите другой браузер.

Хотя спецификация HTML5 не устанавливает никаких жестких правил в отношении максимального объема хранилища, большинство браузеров ограничивают его 5 Мбайт. В этот объем можно упаковать много данных, но его будет недостаточно, если вы хотите использовать локальное хранилище для оптимизации производительности и кэшировать в нем изображения или видео большого объема (и, по правде говоря, локальное хранилище не предназначено для таких целей).

Для хранения большого объема данных все еще развивающийся стандарт базы данных IndexedDB допускает локальное хранение намного большего объема - обычно 50 Мбайт для начала и больше, по согласию пользователя.

Сохранение данных

Прежде чем поместить фрагмент информации в локальное хранилище или хранилище сеансов, ему необходимо присвоить описательное имя. Это имя называется ключом (key) и нужно для того, чтобы данные можно было извлечь в будущем.

Синтаксис для сохранения фрагмента данных следующий:

localStorage = data;

// JS localStorage["username"] = "Ivan Petrov";

Конечно же, сохранять фрагмент статического текста не имеет смысла. Как правило нам требуется сохранять какие-либо переменные данные, например текущую дату, результат математического вычисления или текстовые данные, введенные пользователем в поля формы. Далее приведен пример сохранения введенных пользователем текстовых данных:

Веб-хранилище

Этот текст сохранится в локальном хранилище:
Этот текст сохранится в хранилище данных сессии:

Сохранить Загрузить

Function saveData() { // Получаем значения текстовых полей var localData = document.getElementById("localData").value; var sessionData = document.getElementById("sessionData").value; // Сохраняем текст, введенный в текстовом поле, в локальном хранилище localStorage["localData"] = localData; // Сохраняем текст, введенный в текстовом поле, в хранилище сессий sessionStorage["sessionData"] = sessionData; } function loadData() { // Загружаем сохраненные данные из хранилищ var localData = localStorage["localData"]; var sessionData = sessionStorage["sessionData"]; // Отображаем эти данные в текстовых полях if (localData != null) { document.getElementById("localData").value = localData; } if (sessionData != null) { document.getElementById("sessionData").value = sessionData; } }

Страница содержит два текстовых поля: для локального хранилища (вверху) и для хранилища сеансов (внизу). Нажатие кнопки "Сохранить" сохраняет текст, введенный в текстовые поля, а нажатие кнопки "Загрузить" выводит в полях соответствующие сохраненные данные.

Веб-хранилище также поддерживает менее распространенный синтаксис свойств. Согласно правилам этого синтаксиса, мы обращаемся к ячейке хранения с именем username как localStorage.username, а не localStorage["username"]. Оба типа синтаксиса равнозначны, и использование того или другого является вопросом личного предпочтения.

Веб-хранилище не работает без веб-сервера

В своих исследованиях веб-хранилища вы можете столкнуться с неожиданной проблемой. Во многих браузерах веб-хранилище работает только для страниц, предоставленных веб-сервером. При этом не важно, где расположен сервер, в интернете или на вашем собственном компьютере, самое главное, просто чтобы страницы не запускались с локального жесткого диска (например, двойным щелчком по значку файла страницы).

Эта особенность является побочным эффектом способа, которым браузеры выделяют место в локальное хранилище. Как ранее говорилось, браузеры ограничивают локальное хранилище для каждого веб-сайта 5 Мбайт, для чего им нужно ассоциировать каждую страницу, которая хочет использовать локальное хранилище, с доменом вебсайта.

Что же происходит, если открыть страницу, которая использует веб-хранилище, с локального жесткого диска? Все зависит от браузера. Браузер Internet Explorer, похоже, полностью утрачивает поддержку веб-хранилища. Объекты localStorage и sessionStorage исчезают, и попытка использовать их вызывает ошибку JavaScript.

В браузере Firefox объекты localStorage и sessionStorage остаются на месте и, вроде бы, поддерживаются (даже Modernizr определяет, что поддерживаются), но все, что отправляется на хранение, исчезает неведомо куда. В браузере Chrome опять же что-то другое - большая часть функциональности веб-хранилища работает как следует, но некоторые возможности (например, событие onStorage) не работают.

Подобные проблемы возникают и с использованием интерфейса File API. Поэтому вы избавите себя от многих хлопот, если поместите тестируемую страницу на тестовый сервер, чтобы избежать всех этих неопределенностей.

Поддержка веб-хранилища браузерами

Веб-хранилище является одной из наиболее поддерживаемой возможностью HTML5, с хорошим уровнем поддержки в каждом основном браузере. В таблице ниже приведены минимальные версии основных браузеров, поддерживающих веб-хранилище:

Все эти браузеры предоставляют возможность локального хранилища и хранилища данных сеанса. Но для поддержки события onStorage требуются более поздние версии браузеров, например IE 9, Firefox 4 или Chrome 6.

Самой проблемной является версия IE 7, которая не поддерживает веб-хранилище вообще. В качестве обходного решения можно эмулировать веб-хранилище посредством файлов cookies. Это не совсем идеальное решение, но оно работает. Хотя официального сценария для закрытия этого пробела не существует, несколько хороших отправных точек можно найти на странице HTML5 Cross Browser (в разделе "Web Storage").