Состояния веб-страницы хранят переменные, конфигурации и другие элементы, связанные с данными для веб-сайта. Эти состояния будут определять, как отображается страница, какие компоненты активны, какие из них скрыты или отключены, какой у них цвет и другие безграничные возможности представления на странице.
Государства также могут хранить токены безопасности и другие конфиденциальные данные в определенной степени. Например, файлы 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]
Выводы
Может быть много других способов хранения веб-состояний, другие альтернативы приветствуются в разделе комментариев.
Вскоре мы можем увидеть, как собственные приложения будут заменены их веб-аналогами, с меньшими проблемами совместимости, но обеспечивающими более легкую разработку и доставку.