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

Государства также могут хранить токены безопасности и другие конфиденциальные данные в определенной степени. Например, файлы cookie, созданные сервером, могут храниться в браузере и отправляться обратно на сервер для проверки. Мы также храним токен OAuth в состояниях и отправляем в качестве заголовка запроса.

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

TL;DR

Неустойчивый: исчезает при перезагрузке

  • Локальные переменные
  • Глобальные переменные

Постоянно: остается при перезагрузке

  • Cookie: небольшой токен или хеш-значение
  • Безопасный и только HTTP Cookie: данные сеанса, конфиденциальные данные пользователя
  • Серверная сессия
  • Веб-хранилище
  • IndexedDB
  • Кэш-память
  • URL

Локальные переменные

Вы можете объявить его в области видимости функции, объекта или класса.

По сути, вы храните и используете его в пределах области видимости, и она уменьшится, как только мы выйдем из области видимости или объект будет уничтожен.

Примеры:

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

Вариант использования локальной переменной - временные или личные данные.

Глобальные переменные

Если просто сказать window.varA = 5, varA будет доступна для всех компонентов на странице. Идентификатор элемента на веб-странице также является глобальной переменной:

‹Div id =” abc ”› текст ‹/div›

Доступ к нему можно получить с помощью window.abc.

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

Однако подобное управление глобальными переменными будет иметь множество проблем с масштабируемостью, от управления именами до того, как мы можем поддерживать модульность в различных командах и подсистемах.

Мы должны явно определить, какой префикс какого объекта будет ограничен какой командой. Например, window.TEAM_A_VARS будет использоваться только командой A, но на самом деле другие команды могут изменять данные без ведома команды A, и в будущем будет все труднее отслеживать изменения.

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

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

Cookie-файлы

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

На ранних этапах HTTP 2.0 Cookie пережил свой золотой век с хранением в нем закодированного состояния больших страниц, от учетных данных пользователя, данных временных форм, пользовательских меню, персонализации до данных страниц мастера, размер которых может увеличиваться до нескольких сотен КБ.

С другой стороны, мы обнаружили, что большой размер файлов cookie влияет на производительность и сокращает время отклика. Из-за простоты использования люди злоупотребляли им до такой степени, что он забивал систему. Для отправки на сервер больших данных потребуется больше времени, а также потребуется больше времени ЦП и выделения памяти для декодирования данных Cookie.

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

Безопасный и HTTPOnly Cookie

Это файл cookie, но с безопасным флагом. (Https://en.wikipedia.org/wiki/Secure_cookie)

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

HTTPOnly Cookie предназначен для данных, которые будут созданы сервером и прочитаны только сервером. Обычно он используется для сеанса: аутентификация или отслеживание. Этот флаг полезен для хранения сеанса пользователя и предотвращения его чтения вредоносным кодом JS.

Серверная сессия

Вместо того, чтобы хранить данные в браузере, мы также можем хранить их на сервере. Этот метод полезен, если ваша веб-страница отображается на стороне сервера (SSR). Если нет, должен быть механизм для получения переменных, возможно, через API.

Хранение данных на сервере по-прежнему будет включать cookie в качестве хранилища идентификаторов сеансов.

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

Пример использования сеанса сервера - хранение кэширования данных и конфигурации системы. Его также можно использовать для хранения данных персонализации пользователя.

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

Введение в HTML5 принесло нам веб-хранилище. Как следует из названия, это хранилище для Интернета, размещенное в клиенте (браузере). Это хранилище предназначено для размещения больших данных для использования веб-сайтом.

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

Другой вариант использования - сохранить ответ от серверного API, который, скорее всего, не изменился. Мы также можем хранить много-много флагов без ограничений.

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

Существует два типа веб-хранилищ: сессионное и локальное. Хранилище сеансов сохраняется на вкладке браузера. Если вкладка закрыта, все данные исчезнут. Между тем, локальное хранилище сохраняется во всем приложении браузера. Он никогда не исчезнет, ​​и к нему можно будет получить доступ через вкладки в одном домене.

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

IndexDB

Это расширенная версия Web Storage, заменяющая WebSQL. IndexDB - это структурированная версия веб-хранилища. IndexDB - это не просто пара "ключ-значение", а облегченная версия базы данных, но в веб-браузере. Мы можем хранить данные и делать к ним запросы.

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

Хранилище кеша

С появлением Service Worker и PWA веб-браузер получил возможность вести себя как собственное приложение. Пользователь может установить «веб-страницу» в виде значка на рабочем столе.

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

Пример использования этого кеш-хранилища для хранения:

  • ресурсы (js, css, изображения)
  • Ответы AJAX
  • пользовательские конфигурации и другие данные с возможностью кеширования

URL

И последнее, но не менее важное: URL.

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

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

Открыть домашнюю страницу (http://news.abc) - ›нажмите первую новость -› новости, отображаемые на странице

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

Http://news.abc? postId = 1234

Добавление идентификатора в URL-адрес как postId - это способ хранения переменной. Из URL-адреса мы можем предположить, что 1234 - это идентификатор данных, который мы ищем.

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

Http://news.abc? postId = 1234 # showSubcribeModal

У нас может быть флаг из #showSubscribeModal, когда он есть, будет показано модальное окно.

То, что я уже упоминал об ограничении технологии, связано с тем, что когда мы изменяем запрос URL, нам потребуется, чтобы страница выполняла перезагрузку страницы, а это не приемлемое решение. Вот почему используется хэштег. Но это только добавляет двусмысленности, действительно ли это данные на странице или закладка элемента.

В настоящее время браузер поддерживает history pushstate, где мы можем изменить URL-адрес, не перезагружая его. Мы можем хранить там столько флагов, сколько нам нужно, и после перезагрузки предполагаемое поведение будет сохранено так же, как и до того, как мы его перезагружали.

Этот метод обеспечивает согласованное поведение на всей странице и не требует объявления глобальной переменной внутри кода, поскольку он может быть прочитан любым компонентом страницы с помощью API window.location.href.

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

Мы нанимаем на Blibli.com Бандунг и Джакарта

Заинтересованы в настройке Интернета и работают с передовыми технологиями? Присоединяйтесь к нам, инженеры-фронтенд-инженеры Blibli.com. Мы также открываем офис в Бандунге.

Вы можете связаться со мной напрямую Hidayat Febiansyah по электронной почте [email protected]

Выводы

Может быть много других способов хранения веб-состояний, другие альтернативы приветствуются в разделе комментариев.

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