что такое localstorage javascript
LocalStorage на пальцах
Авторизуйтесь
LocalStorage на пальцах
Один из наших читателей прислал статью с рассказом о HTML5 LocalStorage в браузерах. Передаём ему слово.
Я постарался написать самое простое и понятное руководство по использованию технологии localStorage. Статья получилась совсем небольшой, в силу того, что и сама технология и средства работы с ней не несут ничего сложного. Для старта вам достаточно чуть-чуть знать JavaScript. Итак, уделите этой статье 10 минут и вы смело сможете добавить себе в резюме строчку «умею работать с localStorage».
Что такое localStorage?
Так выглядит JavaScript объект:
А так выглядит JSON. Почти так же как обычный js-объект, только все свойства должны быть заключены в кавычки.
Чтобы понять, что такое localStorage, просто представьте, что где-то у вас в браузере встроен такой объект, которым мы можем пользоваться. При этом данный объект не очищает значения, которые мы туда запишем, если мы перезагрузим страницу или даже совсем закроем браузер.
Если говорить языком JavaScript, то localStorage это свойство глобального объекта браузера (window). К нему можно обращаться как window.localStorage или просто localStorage.
Еще стоит сказать, что у браузера существует клон localStorage, который называется sessionStorage. Их разница только в том, что последний хранит данные только для одной вкладки (сессии) и просто очистит свое пространство как только мы закроем вкладку
3–4 декабря, Онлайн, Беcплатно
Давайте посмотрим на него вживую. Например, в Google Chrome вам надо открыть DevTools (F12), перейти на вкладку «Resourses» и на левой панели вы увидите localStorage для данного домена и все значения, что оно содержит.
Зачем мне нужен localStorage?
LocalStorage нужен только для одного — хранить определенные данные между сессиями пользователя. Можно придумать тысячу и одну вещь, которую можно хранить в локальном хранилище браузера. Например, браузерные игры, которые используют его как сохраненку, или записать момент, на котором пользователь остановился при просмотре видео, различные данные для форм и т.д.
Как мне начать работать с localStorage?
Работа с localStorage очень напоминает работу с объектами в JavaScript. Существует несколько методов для работы с ним.
Метод который добавляет в localStorage новый ключ со значением (а если такой ключ уже существует, то перезаписывает новым значением). Пишем, например, localStorage.setItem(‘myKey’, ‘myValue’);
Берем определенное значение из хранилища по ключу.
Очищаем все хранилище
Сейчас вы можете открыть вкладку с localStorage вашего браузера и самостоятельно потренироваться записывать и извлекать данные из этого хранилища. Если что — весь код пишем в js-файл.
Также хочется отметить, что localStorage отлично работает и с вложенными структурами, например, объектами.
Вы также должны знать, что браузеры выделяют 5мб под localStorage. И если вы его превысите — получите исключение QUOTA_EXCEEDED_ERR. Кстати, c его помощью можно проверять есть ли в вашем хранилище еще место.
Вместо заключения
Мне бы хотелось, чтобы из этой небольшой статьи разработчики сделали для себя простой вывод, что данная технология уже вовсю может использоваться у вас на проектах. У нее хорошая стандартизация и отличная поддержка, которая со временем только развивается.
LocalStorage, sessionStorage
Объекты веб-хранилища localStorage и sessionStorage позволяют хранить пары ключ/значение в браузере.
Что в них важно – данные, которые в них записаны, сохраняются после обновления страницы (в случае sessionStorage ) и даже после перезапуска браузера (при использовании localStorage ). Скоро мы это увидим.
Но ведь у нас уже есть куки. Зачем тогда эти объекты?
Объекты хранилища localStorage и sessionStorage предоставляют одинаковые методы и свойства:
Давайте посмотрим, как это работает.
Демо localStorage
Основные особенности localStorage :
Например, если запустить этот код…
…И закрыть/открыть браузер или открыть ту же страницу в другом окне, то можно получить данные следующим образом:
Нам достаточно находиться на том же источнике (домен/протокол/порт), при этом URL-путь может быть разным.
Объект localStorage доступен всем окнам из одного источника, поэтому, если мы устанавливаем данные в одном окне, изменения становятся видимыми в другом.
Доступ как к обычному объекту
Также можно получать/записывать данные, как в обычный объект:
Это возможно по историческим причинам и, как правило, работает, но обычно не рекомендуется, потому что:
Перебор ключей
Методы, которые мы видим, позволяют читать/писать/удалять данные. А как получить все значения или ключи?
К сожалению, объекты веб-хранилища нельзя перебрать в цикле, они не итерируемы.
Но можно пройти по ним, как по обычным массивам:
Здесь перебираются ключи, но вместе с этим выводятся несколько встроенных полей, которые нам не нужны:
…Поэтому нам нужно либо отфильтровать поля из прототипа проверкой hasOwnProperty :
…Либо просто получить «собственные» ключи с помощью Object.keys, а затем при необходимости вывести их при помощи цикла:
Последнее работает, потому что Object.keys возвращает только ключи, принадлежащие объекту, игнорируя прототип.
Только строки
Обратите внимание, что ключ и значение должны быть строками.
Если мы используем любой другой тип, например число или объект, то он автоматически преобразуется в строку:
Мы можем использовать JSON для хранения объектов:
Также возможно привести к строке весь объект хранилища, например для отладки:
sessionStorage
Свойства и методы такие же, но есть существенные ограничения:
Давайте посмотрим на это в действии.
Запустите этот код…
…И обновите страницу. Вы всё ещё можете получить данные:
Так получилось, потому что sessionStorage привязан не только к источнику, но и к вкладке браузера. Поэтому sessionStorage используется нечасто.
Событие storage
Представьте, что у вас есть два окна с одним и тем же сайтом. Хранилище localStorage разделяется между ними.
Вы можете открыть эту страницу в двух окнах браузера, чтобы проверить приведённый ниже код.
Обратите внимание, что событие также содержит: event.url – url-адрес документа, в котором данные обновились.
Это позволяет разным окнам одного источника обмениваться сообщениями.
Современные браузеры также поддерживают Broadcast channel API специальный API для связи между окнами одного источника, он более полнофункциональный, но менее поддерживаемый. Существуют библиотеки (полифилы), которые эмулируют это API на основе localStorage и делают его доступным везде.
Итого
Объекты веб-хранилища localStorage и sessionStorage позволяют хранить пары ключ/значение в браузере.
Задачи
Автосохранение поля формы
Когда пользователь закроет страницу и потом откроет её заново он должен увидеть последнее введённое значение.
Почему не стоит использовать LocalStorage
Привет, Хабр! Представляю вашему вниманию перевод статьи «Please Stop Using Local Storage» автора Randall Degges.
Все больше разработчиков используют localStorage для хранения данных, в том числе и конфиденциальных, даже не подозревая, что тем самым подвергают свои сайты взлому. Именно поэтому я призываю отказаться от такой практики, и в этой статье постараюсь аргументированно обосновать свою точку зрения.
Введение
Итак, localStorage — новая особенность HTML5, позволяющая хранить любую информацию в пользовательском браузере благодаря JavaScript. Это старый добрый JS-объект, в который можно добавлять и удалять пары ключ/значение. Давайте посмотрим на пример небольшого кода:
Запустив этот код на тестовой HTML-странице, мы увидим в alert-окне фразу «Петя предпочитает чёрный цвет». Если же зайти в инструменты разработчика, предварительно закомментировав строки с удалением данных, то можно убедиться, что оба значения сохранились в локальном хранилище вашего браузера.
Теперь вас может заинтересовать следующий вопрос: есть ли способ использовать локальное хранилище так, чтобы сохраненные данные автоматически удалялись? К счастью, разработчики HTML5 позаботились об этом, добавив глобальный объект sessionStorage, работающий точно так же, как и localStorage, за исключением одного: все хранящиеся в нем данные удаляются, когда пользователь закрывает вкладку браузера.
Преимущества
Несмотря на то, что весь смысл этой статьи заключается в том, чтобы отговорить вас использовать localStorage, у него все же есть ряд преимуществ.
Во-первых, это чистый JavaScript! Одна из неприятных вещей, касающихся cookies (которые, по сути, являются единственной реальной альтернативой локальному хранилищу) заключается в том, что они должны быть созданы сервером. Ужас, ведь работа с веб-серверами скучна и трудоёмка. Если вы создаете статичный сайт (например, SPA), то использование localStorage позволит ему работать без какого-либо бекенда. Это довольно мощная концепция и одна из основных причин, по которым такая практика популярна среди разработчиков.
Ещё одно достоинство заключается в том, что localStorage располагает как минимум 5 Мб для хранения данных (этот размер поддерживается всеми основными веб-браузерами), что на порядок больше, чем у cookie-файлов (
4 Кб). Это дает весомое преимущество, если есть необходимость кэшировать относительно большой объём данных приложения в браузере для последующего использования.
Недостатки
У localStorage очень простое API, многие разработчики даже не представляют, насколько оно простое. Рассмотрим подробнее:
Выходит, что localStorage является хорошим инструментом только при соблюдении ряда условий.
Безопасность
Дело вот в чем: большинство минусов локального хранилища незначительны. Но вопрос безопасности — решающий фактор, поэтому поговорим о нем более подробно.
Итак, localStorage НЕБЕЗОПАСЕН! Совсем! Каждый, кто использует его для хранения конфиденциальных данных, поступает неправильно.
Давайте разберемся, что понимается под конфиденциальными данными:
— Идентификаторы пользователей
— Идентификаторы сессий
— JWT (JSON Web Token)
— Персональная информация
— Информация о кредитной карте
— API-ключи
— Любая другая информация, которую вы бы не стали публиковать публично
LocalStorage разрабатывался не как безопасный механизм хранения данных в браузере, а как простое хранилище ключей и значений с целью облегчения создания небольших сайтов/веб-приложений. И все. Что, по вашему, самое опасное в мире? Верно! JavaScript. Поэтому, когда захотите сохранить что-нибудь важное в локальном хранилище, представьте, что хотите спрятать секретнейшую информацию в самом ненадежном сейфе на планете. Не лучшая идея.
На самом деле проблема заключается в межсайтовом скриптинге (XSS). Не хочу грузить вас подробным объяснением этой уязвимости, поэтому постараюсь объяснить вкратце: если хакер сможет запустить JavaScript-код на вашем сайте, то он запросто вытащит всю информацию из localStorage и отправит её на свой сервер, тем самым заполучив, например, данные о пользовательской сессии.
Вы можете возразить: «Да ну? Мой сайт безопасен. Никто не сможет запустить какой-либо скрипт на моем сайте». И вот тут загвоздка. В теории вы абсолютно правы, однако на деле этого фактически невозможно достичь. Давайте разберемся, почему.
Наверняка ваш сайт содержит скрипты, которые загружаются с других серверов. Cамыми распространенными вариантами являются ссылки на:
— Bootstrap
— jQuery
— Vue, React, Angular и прочие
— Google Analytics
Ну и так далее. Тогда есть вероятность того, что злоумышленник сможет запустить скрипт на вашем сайте. Представим, что он содержит следующий код:
Предположим, что awesomejslibrary.com подвергся атаке, и minifed.js скрипт был так же изменен. В этом случае появляется риск того, что скрипт соберет все данные из localStorage и отправит их на специально созданный для хранения украденной информации API. Выходит, что хакеры украли данные пользователя, при этом ни он, ни вы (как разработчик), не узнаете об этом. Плохой вариант.
Мы все частенько задумываемся над тем, что все js-скрипты нужно размещать локально у себя на сервере, однако на практике такое происходит редко. Во многих компаниях маркетологи могут напрямую вносить изменения на сайт через WYSIWYG-редакторы и прочие инструменты. Отсюда возникает вопрос: вы правда уверены, что нигде на вашем сайте не используется сторонний JS? Я отвечу за вас: нет. Поэтому, чтобы снизить риск утечки пользовательской информации, не храните конфиденциальные данные в localStorage.
Про токены
Хоть мне и кажется, что я достаточно убедительно объяснил, почему не стоит хранить конфиденциальные данные в локальном хранилище, отдельно стоит разъяснить ситуацию с JSON Web Token (JWT). Многие разработчики, которые хранят JWT в localStorage, не понимают, что это, по сути, то же самое, что и имя пользователя / пароль.
Если хакеры скопируют эти токены, то смогут отправлять запросы на ваш сервер, и вы об этом никогда не узнаете. Поэтому обращайтесь с ними так же, как с данными кредитной карты или паролем, а именно — не храните в localStorage, вопреки тысячам туториалов, видео на Youtube и даже курсам программирования в университетах. Это неправильно! Если кто-то советует вам хранить токены в локальном хранлище для аутентификации, покажите им эту статью.
Альтернативы
Итак, после того, как мы убедились, что localStorage — далеко не идеальное решение для хранения информации, время познакомиться с альтернативными вариантами.
Конфиденциальные данные
Для хранения таких данных единственным верным решением является сессия на стороне сервера. Алгоритм следующий:
Эта простая и, что самое главное, безопасная модель. И, разумеется, с помощью нее можно масштабировать проект любого уровня.
Данные, отличные от строк
Если вам необходимо хранить информацию, которая не является конфиденциальной и которая представляет собой что-то сложнее строк, то лучшее решение для этого — IndexedDB. Это транзакционная система БД с низкоуровневым API, являющаяся хорошим вариантом для хранения различных данных (включая файлы/blobs) прямиком в браузере. Более подробную информацию можно получить из гайда от Google.
Оффлайн-данные
Для обеспечения работы приложения без подключения к интернету наилучшим решением будет связка IndexedDB с Cache API (является частью Service Workers), благодаря которой возможно кэширование всех необходимых для корректной работы ресурсов. Отличный туториал по использованию от Google — здесь.
Вывод
Надеюсь, теперь вы понимаете (понимаете ведь?), почему далеко не всегда стоит использовать localStorage. Если вам нужно хранить данные, которые являются публичными, не используются в высокопроизводительных приложениях, точно не займут более 5 Мб и состоят только из строк, то локальное хранилище станет хорошим инструментом для ваших целей.
Во всех остальных случая — не используйте локальное хранилище! Используйте альтернативные решения.
И пожалуйста, я вас просто умоляю, не храните информацию о сессии (вроде JSON Web Token) в localStorage. Это сделает ваш сайт уязвимым для многочисленных атак, которые навредят пользователям.
P.S. Для тех, кто задался вопросом, почему я не упомянул Content Sequiriy Policy (CSP) как способ защиты от XSS. Причина проста: это не поможет в ситуации, которую я описал. Даже если вы используете CSP для проверки всех сторонних доменов, откуда подключаете JavaScript, это не поможет, если сайт из белого списка будет взломан.
P.P.S. Subresource integrity, к сожалению, тоже не является решением проблемы. Для большинства маркетинговых инструментов, рекламных сетей и т.д. (которые являются наиболее распространёнными сторонними скриптами) subresource integrity почти никогда не используется, поскольку поставщики этих скриптов частенько их меняют для расширения функционала и прочих вещей.
Перевод статьи Please stop using Local Storage.
Опубликовано с разрешения автора.
sessionStorage и localStorage
В этой статье познакомимся с веб-хранилищами sessionStorage и localStorage, изучим методы JavaScript для работы, узнаем про их отличия друг от друга, и от файлов cookie, а также рассмотрим примеры использования в Google Tag Manager.
Самая большая проблема при использовании cookie в качестве локального хранилища заключается в том, что:
С появлением HTML5 мы получили доступ к более объемному веб-хранилищу (между 5 и 10 МБайт на каждый домен), которое сохраняет информацию между загрузками страницы и посещениями сайта (даже после выключения и включения компьютера). Кроме того, данные локального хранилища не отправляются на сервер при каждой загрузке страницы, в связи с чем ускоряется работа веб-приложения.
Существуют два основных типа веб-хранилища:
Оба типа являются свойствами глобального объекта браузера (window). К ним можно обращаться как window.sessionStorage (или sessionStorage) и window.localStorage (или localStorage) соответственно. В них можно хранить ТОЛЬКО СТРОКОВЫЕ ДАННЫЕ для ключей и их значений.
Разберем каждый из них подробнее.
sessionStorage (сессионное хранилище, хранилище сессии)
Объект sessionStorage используется гораздо реже, чем localStorage.
localStorage (локальное хранилище)
Каждый домен имеет доступ к своему хранилищу данных localStorage. Например, localStorage, используемый для, https://osipenkov.ru является отдельным от localStorage, используемым для https://coobiq.com. Субдомены (поддомены) и различные протоколы HTTP (HTTP и HTTPS) имеют независимые друг от друга хранилища данных. Например, localStorage https://gtm.osipenkov.ru используется полностью отдельно от https://osipenkov.ru. Точно так же localStorage https://osipenkov.ru используется отдельно от http://osipenkov.ru.
Некоторые браузеры блокируют localStorage в режиме инкогнито. localStorage работает даже с отключенными cookie.
Примечание: не храните в localStorage конфиденциальную информацию и личные данные пользователией, включая имя, фамилию, дату рождения, пароли, номера кредитных карт, номер телефона, e-mail и многое другое.
Что можно хранить и для чего использовать?
Хранение данных в локальном хранилище очень распространено. Классическим примером использования локального хранилища является веб-приложение типа Ежедневник, когда пользователь составляет список дел на день, и по мере выполнения удаляет их из списка. Для выполнения этой задачи не нужен сервер, подойдет localStorage. Кликнув по задаче из списка, которое человек уже сделал, она будет удаляться с локального хранилища и, следовательно, показываться пользователю больше не будет. Локальное хранилище часто используется для сохранения настроек пользователя на сайте (выбор темы оформления, вид отображения информации), чтобы при следующем заходе эти данные уже были применены к его профилю и повторно не вводились.
Посмотреть, что из себя представляют sessionStorage и localStorage, какие данные там хранятся у разных сайтов, можно в консоли разработчика на вкладе Application (для браузера Google Chrome).
Веб-хранилище (вкладка Application)
Либо использовать команды sessionStorage и localStorage на вкладке Console:
Команда sessionStorage или localStorage (вкладка Console)
Карточка пользователя по одному из чатов
sessionStorage vs localStorage vs cookies
Нагляднее всего продемонстрировать отличия между sessionStorage, localStorage и cookies с помощью таблицы:
Отличие cookies от sessionStorage и localStorage
Помимо этого, согласно правилам обработки персональных данных, установленных Генеральным регламентом ЕС о защите персональных данных (или GDPR — General Data Protection Regulation), владелец сайта должен получать разрешение от пользователей на использование файлов cookie. Для локального хранилища этого не требуется.
Как вы уже знаете, сейчас в части браузеров используется технология «умной защиты от слежения», которая предоставляет отчеты о заблокированных трекерах (в том числе и счетчиках веб-аналитики), тем самым препятствуется слежение за пользователями и показ им персонализированной рекламы с помощью файлов cookie. Хоть мы и можем устанавливать срок жизни куки, их время все равно зависит от настроек самих браузеров. Например, система интеллектуального отслеживания (Intelligent Tracking Prevention, ITP 2.2) Apple ограничивает в Safari использование основных файлов cookie (first-party) до 1 дня. В результате файлы cookie, установленные рекламными сервисами, например, Facebook, Google или Яндексом, для измерения трафика сайта и атрибуции рекламы, будут удалены через 24 часа. И если человек нажимает на рекламное объявление в пятницу, а затем решает отложить покупку в выходные, то в понедельник у нас уже не будет cookie, чтобы показать ему рекламу и напомнить о приобретении. Остается только надеется на то, что человек запомнил наш сайт и вернется сам.
Чтобы отслеживать пользователей больше этого времени, можно использовать localStorage. Но и тут разочарование относительно пользователей Safari. В последних обновлениях разработчики добавили ограничение в 7 дней, то есть срок жизни данных в локальном хранилище теперь ограничен. Когда пользователь просматривает сайт через Safari, счетчик становится равен 7 дням. В течение этого времени он должен повторно вернуться на сайт, чтобы мы смогли использовать информацию из локального хранилища. В противном случае данные по истечении этого времени будут удалены из localStorage.
Так или иначе, sessionStorage и localStorage активно используются разработчиками при разработке веб-приложений, а интернет-маркетологами как альтернатива файлам cookie. В блоге Симо Ахавы (Simo Ahava) есть статья, которая посвящена хранению Client ID в localStorage для Google Analytics.
Методы и свойства
Объекты хранилища sessionStorage и localStorage предоставляют одинаковые методы и свойства:
Запись данных в хранилище
Функция setItem(key, value) принимает ключ в качестве первого аргумента и значение в качестве второго аргумента. Как упоминалось ранее, все данные должны быть строками. Примеры установки:
Как использовать localStorage и sessionStorage в JavaScript
Введение
LocalStorage и sessionStorage, часть API веб-хранилища, – это два отличных инструмента для локального хранения пар ключ/значение.
Использование localStorage и sessionStorage для хранения данных является альтернативой использованию cookies и имеет ряд преимуществ:
Он также совместим со всеми современными браузерами, поэтому вы можете использовать его уже сегодня без каких-либо проблем.
Cookies по-прежнему полезны, особенно когда речь идет об аутентификации, но бывают случаи, когда localStorage или sessionStorage могут быть лучшей альтернативой.
Предпосылки
Чтобы успешно освоить этот материал, вам понадобится следующее:
Понимание localStorage и sessionStorage
localStorage и sessionStorage практически идентичны и имеют одинаковый API.
Разница в том, что при использовании sessionStorage данные сохраняются только до закрытия окна или вкладки.
При использовании localStorage данные сохраняются до тех пор, пока пользователь вручную не очистит кэш браузера или пока веб-приложение не очистит данные.
В этом руководстве рассматривается localStorage, но синтаксис sessionStorage такой же.
Создание, чтение и обновление записей
Вы можете создавать записи для localStorage с помощью метода setItem().
Метод setItem() принимает два аргумента, ключ и соответствующее значение:
Чтобы прочитать записи, используйте метод getItem()
Метод getItem() принимает аргумент, который должен быть ключом.
Эта функция вернет соответствующее значение в виде строки:
Этот код присваивает myItem значение ‘Value’, которое является соответствующим параметром для ключа.
Обновление элемента выполняется с помощью метода setItem().
Опять же, необходимы два аргумента. Аргумент key будет существующим ключом, а аргумент value – новым значением:
Теперь значением ключа localStorage будет ‘New Value’ вместо ‘Value’.
Вы можете создавать, читать и обновлять записи в объекте localStorage
Вы также можете удалять отдельные записи и удалять все записи в формате localStorage
Удаление записей
Вы можете удалить элемент с помощью метода removeItem()
Метод removeItem() принимает аргумент, который будет ключом объекта localStorage
Вы также можете очистить все элементы в localStorage.
Это можно сделать с помощью метода clear().
Вот как очистить все, что хранится в localStorage:
Эти методы дают вам возможность быстро удалять и извлекать элементы из localStorage.
Однако у localStorage есть некоторые ограничения.
И localStorage, и sessionStorage могут хранить только строки.
Чтобы обойти эту проблему, вам нужно использовать методы JSON.
Хранение нестроковых значений с помощью JSON
localStorage может хранить только строковые значения.
Если вы хотите хранить объекты или массивы в качестве значений в localStorage, вы можете использовать JSON.stringify() для преобразования их в строки.
При создании или обновлении пар ключ/значение в localStorage используйте JSON.stringify() с объектом или массивом в качестве аргумента:
Хотя myObj является объектом, JSON.stringify(myObj) преобразуется в строку.
Таким образом, myObj теперь является значением localStorage.
Теперь элемент устанавливается равным значению ключа.
В приведенном выше фрагменте кода значение ключа было установлено в строковую версию myObj. Использование JSON.parse превращает myObj обратно в объект. Поэтому элемент устанавливается равным myObj как объект, а не как строка.
Возможность преобразовывать массивы и объекты в строки с помощью JSON.stringify и обратно с помощью JSON.parse очень полезна.
Вам также потребуется знать, как проверить, пуст ли localStorage или нет.
Проверяем пуст или нет
В этом шаге вы проверите наличие элементов в localStorage.
Вы можете использовать if, чтобы узнать, содержит ли localStorage элементы или он пуст.
Для этого используем длину localStorage:
Если localStorage.length больше 0, то внутри объекта localStorage есть элементы
Добавим else для ситуации отсутствия элементов в localStorage:
Вы можете включить код для применения в else if и else.
localStorage и sessionStorage не поддерживают метод forEach localStorage через элементы в localStorage, поэтому используйте цикл for.
Функция key() принимает целое число в качестве аргумента и возвращает соответствующий ключ.
С помощью for передайте i как целое число для key():
Для возврата соответствующего значения ключа используйте getItem:
Создайте console.log для вывода ключа и значения на экран:
key() очень полезна для итерации по localStorage с помощью циклов for.
Проверка совместимости.
Вы можете протестировать поддержку localStorage, проверив наличие окна в объекте с помощью оператора if.
Заключение
Для хранения пар ключ/значение можно использовать localStorage или sessionStorage.
Существуют методы, позволяющие взаимодействовать с элементами внутри localStorage.
В этом руководстве вы создали, удалили и обновили записи в localStorage. Вы также преобразовывали данные из объектов и массивов в строки и наоборот, используя методы JSON.