Полная сигнатура driver

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

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

Свойство driver в конфигурации представляет собой не «метод», а механизм определения используемых бэкендов. В публичном API оно связано с:

  • выбором предпочтительных драйверов;
  • управлением fallback-цепочкой;
  • установкой активного драйвера;
  • получением текущей конфигурации.

Полная сигнатура driver

В контексте localForage корректная сигнатура использования driver выглядит следующим образом:

localforage.driver(driversArray)

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

localforage.config({
  driver: [/* array of drivers */]
})

и отдельный метод выбора:

localforage.setDriver(driverName)

Формальное определение сигнатуры setDriver как части driver-системы

Хотя driver не является самостоятельной функцией, его логика реализуется через:

setDriver(driver: string | string[]): Promise<void>

или в расширенной интерпретации:

setDriver(driver: string | string[]): Promise<LocalForage>

Параметры

driver — строка или массив строк Представляет один или несколько идентификаторов драйверов:

  • localforage.INDEXEDDB
  • localforage.WEBSQL
  • localforage.LOCALSTORAGE

При передаче массива система выстраивает приоритетную цепочку выбора.

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

Метод возвращает Promise, который:

  • резолвится после успешной активации драйвера;
  • может резолвиться самим экземпляром localforage (в некоторых реализациях);
  • отклоняется при отсутствии доступных поддерживаемых драйверов.

Внутреннее поведение driver-цепочки

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

1. Проверка поддержки

Каждый драйвер проходит проверку:

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

2. Инициализация backend-слоя

После выбора подходящего драйвера создаётся адаптер:

  • IndexedDB адаптер инициализирует объектную базу;
  • WebSQL адаптер открывает SQL-базу;
  • localStorage адаптер работает через синхронный key-value слой.

3. Переключение контекста

Активный драйвер подменяет внутренние методы:

  • getItem
  • setItem
  • removeItem
  • clear
  • iterate

Связь driver с конфигурацией

Поле driver часто используется в конфигурации:

localforage.config({
  driver: [
    localforage.INDEXEDDB,
    localforage.WEBSQL,
    localforage.LOCALSTORAGE
  ]
})

Это означает:

  • попытка использовать IndexedDB как основной механизм;
  • fallback на WebSQL при невозможности;
  • последний резерв — localStorage.

Поведение при ошибках выбора driver

Если ни один драйвер не доступен:

  • возвращается rejected Promise;
  • все операции хранения становятся недоступны;
  • экземпляр остаётся инициализированным, но неработоспособным.

Типичная ошибка:

No available storage method found.

Динамическая смена driver

Метод setDriver позволяет переключать backend во время выполнения:

await localforage.setDriver(localforage.INDEXEDDB);

Особенности:

  • существующие данные не мигрируются автоматически;
  • переключение влияет только на новые операции;
  • поведение зависит от реализации адаптера.

Типизация driver в расширенной модели

В TypeScript-ориентированном описании:

type DriverName =
  | typeof localforage.INDEXEDDB
  | typeof localforage.WEBSQL
  | typeof localforage.LOCALSTORAGE;

interface LocalForageDriverSet {
  setDriver(driver: DriverName | DriverName[]): Promise<void>;
}

Приоритеты driver и стратегия fallback

Механизм выбора строится по принципу приоритетного списка:

  1. Проверяется первый driver
  2. При неудаче — переход ко второму
  3. И так далее до успешного выбора

Это позволяет:

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

Внутренние зависимости driver-модуля

Driver-система опирается на:

  • адаптеры хранения;
  • promise-обёртки асинхронных операций;
  • детекторы поддержки API;
  • внутренний registry драйверов.

Регистрация драйвера происходит на уровне инициализации библиотеки:

localforage.defineDriver(customDriver)

Поведение driver при повторной инициализации

Повторный вызов setDriver:

  • переинициализирует backend;
  • сбрасывает текущий контекст;
  • может вызвать повторное создание connection pool.

Важно, что:

  • ключи и данные могут остаться в старом backend;
  • доступ к ним зависит от выбранного драйвера.

Ограничения driver-механизма

Основные ограничения:

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

Роль driver в общей модели localForage

Driver является фундаментальным слоем, на котором строится:

  • унификация API хранения;
  • кросс-браузерная совместимость;
  • прозрачность работы с асинхронными хранилищами;
  • абстракция над различными storage-движками.

Без корректно выбранного driver вся система localForage теряет смысл, поскольку API перестаёт иметь реальный backend для выполнения операций хранения.

Оглавление