Поведение при недоступности выбранного драйвера

В библиотеке localForage выбор механизма хранения данных строится на абстракции драйверов. Каждый драйвер — это адаптер к конкретному API браузера: IndexedDB, WebSQL или localStorage. При этом ключевым аспектом работы становится сценарий, при котором выбранный или предпочтительный драйвер оказывается недоступным в текущей среде исполнения.

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

Причины недоступности драйвера

Ситуации, при которых драйвер считается недоступным, разнообразны и зависят от браузера, режима работы и ограничений среды:

  • отсутствие поддержки API (например, IndexedDB в устаревших браузерах);
  • отключённые механизмы хранения в приватных режимах;
  • ограничения политики безопасности (sandbox iframe, CSP);
  • повреждённое или заблокированное хранилище;
  • исчерпание квоты;
  • принудительное отключение WebSQL в современных браузерах.

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

Механизм проверки совместимости

Перед установкой драйвера выполняется проверка его пригодности для текущей среды. Она реализуется через метод supports.

Внутри каждого драйвера определяется логика вида:

  • наличие глобального объекта (indexedDB, openDatabase, localStorage);
  • возможность выполнения тестовой операции записи;
  • отсутствие исключений при инициализации.

Если хотя бы один критический критерий не выполняется, драйвер считается неподдерживаемым.

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

Поведение при явном выборе недоступного драйвера

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

Возможны следующие сценарии:

  1. Драйвер поддерживается Установка проходит успешно, дальнейшие операции используют выбранный механизм.

  2. Драйвер не поддерживается Возникает отклонение промиса. Инициализация прекращается, если не предусмотрена обработка fallback-логики на уровне приложения.

  3. Частичная поддержка В некоторых окружениях API присутствует, но функционально нестабилен (например, приватный режим Safari). В этом случае драйвер может формально пройти проверку, но операции записи будут завершаться ошибками.

Автоматический fallback при конфигурации нескольких драйверов

При указании массива драйверов через конфигурацию setDriver([...]) активируется механизм последовательного выбора.

Алгоритм работы:

  1. Драйверы перебираются в порядке приоритета.
  2. Для каждого выполняется проверка supports.
  3. Первый совместимый драйвер становится активным.
  4. Остальные игнорируются до следующей переинициализации.

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

Поведение при отсутствии доступных драйверов

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

  • операции setItem, getItem, removeItem возвращают отклонённые промисы;
  • внутренний статус хранилища остаётся неготовым;
  • очередь операций может накапливаться, но не выполняется.

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

Роль localStorage как резервного механизма

localStorage часто используется как последний fallback-уровень. Его особенности:

  • синхронный API;
  • ограниченный объём;
  • высокая совместимость.

Однако недоступность localStorage также возможна:

  • режимы приватного просмотра в некоторых браузерах;
  • блокировка cookies и storage;
  • строгие корпоративные политики безопасности.

В таких случаях fallback-цепочка обрывается окончательно.

Асинхронная инициализация и состояние ready

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

До завершения инициализации возможны следующие эффекты недоступности:

  • операции постановки в очередь;
  • временные отказы в выполнении;
  • задержки при первом доступе к API.

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

Особенности поведения в приватных режимах браузеров

Приватные режимы представляют отдельный класс проблем:

  • IndexedDB может быть доступен, но с ограничениями на квоты;
  • localStorage может работать в ограниченном режиме или полностью блокироваться;
  • WebSQL может отсутствовать полностью.

В таких условиях localForage может:

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

Ошибки записи как индикатор недоступности

Некоторые сценарии недоступности драйвера проявляются не на этапе инициализации, а при выполнении операций:

  • QuotaExceededError при превышении лимита;
  • TransactionInactiveError в IndexedDB при сбоях транзакций;
  • SecurityError при ограничениях доступа.

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

Особенности переключения драйверов в runtime

localForage не выполняет автоматическое переключение драйвера после его установки. Это означает:

  • выбранный драйвер остаётся активным до явного переинициализирования;
  • сбои во время работы не приводят к автоматическому fallback;
  • смена драйвера требует повторного вызова конфигурации.

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

Кэширование состояния доступности драйверов

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

  • повторные проверки выполняются быстрее;
  • изменения среды (например, включение/выключение приватного режима) могут не учитываться;
  • состояние поддержки может становиться устаревшим до перезагрузки контекста.

Влияние iframe и sandbox-ограничений

При работе внутри iframe с ограничениями sandbox доступ к storage API может быть заблокирован:

  • IndexedDB недоступен при отсутствии соответствующих разрешений;
  • localStorage может быть изолирован или отключён;
  • WebSQL не поддерживается в ограниченных контекстах.

localForage в таких условиях ведёт себя как в полностью неподдерживаемой среде: драйверы исключаются на этапе проверки или проваливаются при первой операции.

Обобщённая модель поведения

Поведение при недоступности драйвера можно свести к трёхуровневой модели:

  1. Проверка поддержки Драйвер либо допускается, либо исключается до использования.

  2. Инициализация Выбранный драйвер становится активным, формируется состояние готовности.

  3. Исполнение операций При скрытых ограничениях ошибки проявляются в момент чтения или записи.

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

Итоговая структура поведения

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

Оглавление