Member Junction
    Preparing search index...

    Class InMemoryLocalStorageProvider

    In-memory implementation of ILocalStorageProvider. Useful for server-side environments (Node.js) where browser storage APIs like localStorage or IndexedDB are not available, and as a default fallback wherever a storage provider is required but no persistence is needed.

    Stores values by reference — no serialization. Mirrors the IndexedDB provider's structured-clone semantics (preserves Date, Map, Set, typed arrays, etc.) without the storage round-trip cost.

    Note: Data is not persisted across process restarts. Suitable for caching scenarios where persistence is not required.

    Implements

    Index

    Constructors

    Methods

    • 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.

      Type Parameters

      • T = unknown

        Expected type of the stored value. Caller-controlled — the provider does not validate the runtime shape against this type. Falls back to unknown.

      Parameters

      • key: string

        The key to retrieve

      • Optionalcategory: string

        Optional category for key isolation (e.g., 'RunViewCache', 'Metadata')

      Returns Promise<T>

    • 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.

      Type Parameters

      • T = unknown

        Expected type of all stored values. Caller-controlled.

      Parameters

      • keys: string[]

        The keys to retrieve. Duplicates are deduplicated; the returned map has one entry per unique key.

      • Optionalcategory: string

        Optional category for key isolation (applies to all keys)

      Returns Promise<Map<string, T>>

    • 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.

      Type Parameters

      • T

        Type of the value being stored. Caller-controlled.

      Parameters

      • key: string

        The key to store under

      • value: T

        The value to store

      • Optionalcategory: string

        Optional category for key isolation

      Returns Promise<void>