Interface ILocalStorageProvider

Clears all items in a specific category. If no category is specified, clears the default category only.

Gets all keys in a specific category.

Retrieves a value from storage. The implementation is responsible for any deserialization required by the underlying medium:

• IndexedDB: returns the value directly via structured clone (Date/Map/Set/typed arrays preserved, no parse needed)
• localStorage / Redis: deserializes from JSON internally
• In-memory: returns the stored reference

Returns null for missing keys or corrupt entries.

Batched retrieval — reads N values for N keys in one logical operation.

Returns a Map keyed by the input key strings. Missing keys map to null. The map preserves the original key set so callers can index by key without relying on array-position alignment.

Why batch? IndexedDB serializes transactions on the same object store — Promise.all([...N GetItem calls]) looks parallel but pays per-transaction setup cost (~3–10ms each) for every key. A single transaction with N get() calls amortizes that overhead. Redis can use MGET/pipelines. In-memory implementations have no real win but implement consistently for a uniform API.

Implementations are free to fall back to per-key reads internally if the underlying medium doesn't support batching — the contract is just "read all of these as efficiently as you can". An empty keys array returns an empty map without touching the storage backend.

Removes an item from storage.

Stores a value. Callers should pass plain data (objects/arrays/primitives/Date/etc). Implementations handle any serialization required by the medium:

• IndexedDB: stores natively via structured clone (no string conversion)
• localStorage / Redis: serializes to JSON internally
• In-memory: stores the reference directly

Class instances lose their prototype on retrieval — store the underlying data (e.g. via entity.GetAll()) and reconstruct on read if needed.