Параметр storeName: имя хранилища

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

Роль storeName в архитектуре localForage

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

Параметр storeName участвует в формировании структуры хранения следующим образом:

• в IndexedDB он соответствует имени object store
• в WebSQL он соответствует имени таблицы
• в localStorage используется как часть ключевого префикса

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

Связь с другими параметрами конфигурации

storeName работает в связке с параметрами конфигурации localForage:

• name — имя базы данных (или общий namespace)
• storeName — конкретное хранилище внутри базы
• version — версия IndexedDB базы
• description — описание базы

Комбинация name + storeName формирует уникальный контекст хранения, который влияет на изоляцию данных.

Формирование уникального пространства данных

При инициализации localForage создаётся структура, зависящая от драйвера:

IndexedDB

• database name: значение name
• object store name: значение storeName

Пример:

localforage.config({
  name: 'appDB',
  storeName: 'users'
});

Результат в IndexedDB:

• база данных: appDB
• object store: users

WebSQL

• database name: name
• table name: storeName

Пример структуры таблицы:

CRE ATE   TABLE IF NOT EXISTS users (key unique, value)

localStorage

В localStorage отсутствуют базы и таблицы, поэтому используется ключевое пространство:

appDB/users/someKey

Таким образом storeName становится частью строкового префикса.

Значение storeName для изоляции данных

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

Типичные сценарии:

• разделение пользовательских данных и настроек
• изоляция кэша API от бизнес-данных
• хранение временных и постоянных данных отдельно
• мульти-модульная архитектура (разные подсистемы приложения)

Пример логического разделения:

localforage.config({
  name: 'crmApp',
  storeName: 'clients'
});

localforage.setItem('123', { name: 'Alex' });

Другой модуль:

localforage.config({
  name: 'crmApp',
  storeName: 'settings'
});

localforage.setItem('theme', 'dark');

Обе структуры используют одну базу, но данные не пересекаются.

Ограничения и особенности именования

storeName подчиняется ограничениям драйверов браузера:

IndexedDB

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

WebSQL

• имя таблицы должно быть валидным SQL-идентификатором
• нежелательны пробелы и символы пунктуации

localStorage

• storeName становится частью ключа
• любые символы допустимы, но влияют на читаемость и совместимость

Влияние изменения storeName

Изменение storeName после того, как данные уже записаны, приводит к созданию нового пространства хранения.

Пример:

localforage.config({
  name: 'appDB',
  storeName: 'users'
});

Позже:

localforage.config({
  name: 'appDB',
  storeName: 'accounts'
});

Результат:

• данные из users остаются в старом store
• новый store accounts создаётся пустым
• прямого переноса данных не происходит автоматически

Это важно учитывать при миграциях и рефакторинге.

Поведение при смене драйвера

storeName сохраняет свою роль при переключении драйверов:

• IndexedDB → object store
• WebSQL → table
• localStorage → key prefix

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

Практика именования storeName

Хорошо структурированные проекты используют предсказуемые соглашения:

1. По доменной области

• users
• products
• orders

2. По типу данных

• cache
• session
• metadata

3. По модульной архитектуре

• authModule
• dashboardModule
• analyticsModule

Коллизии и дублирование имен

Хотя storeName изолирует данные, ошибки в именовании могут привести к:

• случайному пересечению логики разных модулей
• перезаписи данных при одинаковом storeName
• трудностям при отладке

Особенно критично использование одинаковых storeName в разных частях приложения при общем значении name базы.

Взаимодействие storeName с производительностью

Влияние параметра косвенное, но проявляется через структуру хранения:

• IndexedDB: количество object store влияет на структуру транзакций
• WebSQL: количество таблиц влияет на схему базы
• localStorage: длинные ключи увеличивают накладные расходы

Чрезмерное дробление на множество storeName может усложнить управление транзакциями и миграциями.

Миграции данных между storeName

localForage не предоставляет встроенной миграции между storeName. Перенос данных выполняется вручную:

async function migrate(oldStore, newStore) {
  const oldLF = localforage.createInstance({
    name: 'appDB',
    storeName: oldStore
  });

  const newLF = localforage.createInstance({
    name: 'appDB',
    storeName: newStore
  });

  await oldLF.iterate(async (value, key) => {
    await newLF.setItem(key, value);
  });
}

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

Изоляция через createInstance

Хотя storeName задаётся глобально через config, более гибкий подход основан на createInstance:

const usersStore = localforage.createInstance({
  name: 'appDB',
  storeName: 'users'
});

const logsStore = localforage.createInstance({
  name: 'appDB',
  storeName: 'logs'
});

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

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

Если storeName не указан явно, используется значение по умолчанию:

keyvaluepairs

Это значение закреплено внутри реализации IndexedDB-драйвера и применяется автоматически при отсутствии пользовательской конфигурации.

Использование дефолтного storeName допустимо для простых сценариев, но ограничивает масштабируемость архитектуры.

Влияние на структуру данных приложения

storeName фактически определяет уровень логической сегментации данных:

• уровень базы (name) — приложение или домен
• уровень storeName — подсистема или тип данных
• уровень key — конкретная сущность

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

Ошибки конфигурации storeName

Частые ошибки включают:

• динамическое изменение storeName без миграции данных
• использование одинакового storeName в разных модулях
• отсутствие стандарта именования
• попытка использовать storeName как фильтр данных вместо разделения пространства

Такие ошибки приводят к фрагментации данных и усложнению отладки.

Использование в крупных приложениях

В масштабных приложениях storeName становится ключевым элементом архитектуры хранения:

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

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