API reference
Every public class, method, and event in @codexo/exojs. Generated from source.
interfaceCacheLayout
How one acquired representation is laid out in persistent storage. This is the boundary between what an asset's source data IS - the asset type's and its codec's business - and how a store physically holds it. A layout decides how many records a representation occupies, what they are called, and how a complete representation is reassembled from them. It knows nothing about IndexedDB, network ordering or resource construction. ## Versioning version is part of every record's persistent identity, so raising it makes previously written records unreachable rather than decoding them under rules they were not written for. There is no migration path by design: a cache is reconstructible, and a version bump simply misses and re-acquires. Most types need exactly one record and should use SingleEntryLayout.
import { CacheLayout } from '@codexo/exojs'How one acquired representation is laid out in persistent storage.
This is the boundary between what an asset's source data IS - the asset type's and its codec's business - and how a store physically holds it. A layout decides how many records a representation occupies, what they are called, and how a complete representation is reassembled from them. It knows nothing about IndexedDB, network ordering or resource construction.
## Versioning
version is part of every record's persistent identity, so raising it makes previously written records unreachable rather than decoding them under rules they were not written for. There is no migration path by design: a cache is reconstructible, and a version bump simply misses and re-acquires.
Most types need exactly one record and should use SingleEntryLayout.
read(context: CacheLayoutContextThe store operations a CacheLayout may use, scoped to one acquisition. A layout addresses its own records by name and never composes a CacheRecordKey itself: t…): Promise<CacheReadResultThe outcome of reading one cache record. A miss and a failure are deliberately different things: a miss resolves to `{ hit: false }`, a store that could not an…<Stored>>write(stored: Stored, context: CacheLayoutContextThe store operations a CacheLayout may use, scoped to one acquisition. A layout addresses its own records by name and never composes a CacheRecordKey itself: t…): Promise<void>version: number