Запрос постоянного хранилища через Storage API

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

В контексте работы с localForage, который абстрагирует IndexedDB, WebSQL и localStorage, особенно важно понимать механизм постоянного (persistent) хранилища, предоставляемый Storage API. Он позволяет запросить у браузера исключение для данных приложения из политики автоматического удаления.

Модель хранения данных в браузере

Браузерное хранилище делится на несколько категорий:

  • временное (temporary storage) — может быть очищено автоматически;
  • постоянное (persistent storage) — защищено от автоматического удаления;
  • кэшируемые ресурсы (Cache API, service worker caches);
  • структурированные данные (IndexedDB, используемый localForage);
  • синхронизируемые хранилища (в некоторых браузерах и экосистемах).

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

Storage API и запрос на постоянство

Storage API предоставляет интерфейс navigator.storage, через который можно управлять характеристиками хранения.

Ключевой метод:

navigator.storage.persist()

Он запрашивает у браузера разрешение на перевод хранилища в режим persistent.

Результат — булево значение:

  • true — доступ к постоянному хранилищу предоставлен;
  • false — запрос отклонён системой или политикой браузера.

Проверка текущего состояния постоянного хранилища

Перед запросом можно проверить, имеет ли приложение уже постоянный статус:

const isPersisted = await navigator.storage.persisted();

Возвращаемое значение:

  • true — данные уже защищены от автоматического удаления;
  • false — хранилище временное и может быть очищено системой.

Запрос на persistent storage

Стандартный сценарий включает проверку текущего статуса и последующий запрос:

async function ensurePersistentStorage() {
  if (!navigator.storage || !navigator.storage.persist) {
    return false;
  }

  const alreadyPersisted = await navigator.storage.persisted();
  if (alreadyPersisted) {
    return true;
  }

  const granted = await navigator.storage.persist();
  return granted;
}

Этот вызов инициирует взаимодействие с политикой браузера. Решение о выдаче статуса зависит от факторов:

  • частота использования сайта;
  • пользовательская активность;
  • тип браузера;
  • наличие установки PWA;
  • общий объём доступного дискового пространства.

Поведение браузеров при принятии решения

Разные браузеры используют собственные алгоритмы оценки “доверенности” источника:

  • Chrome и Chromium-браузеры учитывают engagement score;
  • Firefox опирается на внутренние политики устойчивости данных;
  • Safari имеет более ограниченную и консервативную модель.

Факторы, повышающие вероятность получения persistent storage:

  • установка веб-приложения как PWA;
  • регулярное использование;
  • наличие офлайн-функциональности;
  • активное взаимодействие с сайтом.

Связь persistent storage и localForage

localForage сам по себе не управляет политикой хранения, но напрямую зависит от IndexedDB. При нехватке места браузер может удалить:

  • базы IndexedDB;
  • Service Worker caches;
  • данные Cache API.

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

Запрос persistent storage снижает вероятность такого сценария.

Пример интеграции localForage с проверкой постоянного хранилища

import localforage from "localforage";

async function initStorage() {
  const persisted = await navigator.storage?.persisted?.();

  if (!persisted) {
    await navigator.storage?.persist?.();
  }

  await localforage.config({
    name: "app_database",
    storeName: "cache_store"
  });
}

В этом сценарии сначала фиксируется политика хранения, затем инициализируется localForage.

Контроль квоты и анализ использования памяти

Storage API также предоставляет возможность оценки доступного и занятого пространства:

const estimate = await navigator.storage.estimate();

console.log(estimate.usage);
console.log(estimate.quota);

Поля:

  • usage — объём используемой памяти;
  • quota — общий лимит;
  • usageDetails — детализация по типам хранилищ (в некоторых браузерах).

localForage может занимать значительную долю quota при хранении больших объектов, поэтому контроль использования важен для предотвращения принудительной очистки.

Поведение при отсутствии persistent storage

Если браузер отклоняет запрос, приложение продолжает работать в обычном режиме, но данные становятся уязвимыми:

  • IndexedDB может быть очищена системой;
  • пользователь может не заметить потерю данных;
  • восстановление возможно только через внешние источники (сервер, синхронизация).

Такая модель особенно критична для офлайн-first приложений, где localForage выступает основным хранилищем состояния.

Практические сценарии использования persistent storage

Офлайн-приложения

Приложения, работающие без постоянного соединения с сервером, используют localForage для хранения:

  • пользовательских данных;
  • очередей операций;
  • кешированных ответов API.

Потеря таких данных делает приложение неработоспособным.

PWA и кэширование состояния

Progressive Web Apps часто комбинируют:

  • Service Worker;
  • Cache API;
  • localForage (IndexedDB слой).

Persistent storage снижает риск очистки всей связанной структуры данных браузером.

Долгоживущие пользовательские данные

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

Ограничения и особенности поведения API

  • Запрос persistent storage не гарантирует успех;
  • решение полностью контролируется браузером;
  • некоторые браузеры могут игнорировать запрос без явного уведомления;
  • повторный запрос после отказа может быть ограничен;
  • поведение может отличаться на мобильных устройствах и desktop-средах.

Взаимодействие с политикой приватности и очисткой данных

Браузеры могут очищать временные хранилища при:

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

Persistent storage уменьшает вероятность таких действий, но не отменяет их полностью в случаях ручной очистки или системных ограничений.

Архитектурная роль persistent storage в приложениях с localForage

Использование Storage API формирует дополнительный слой устойчивости поверх IndexedDB:

  • localForage отвечает за абстракцию и удобство доступа;
  • IndexedDB обеспечивает структурированное хранение;
  • Storage API управляет жизненным циклом данных на уровне браузера;
  • persistent flag снижает риск эвикции.

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

Оглавление