Core · class

RemoteSaveStore

Explained in The loop.

class RemoteSaveStore implements KeyValueStore

import { RemoteSaveStore } from '@driftengine/core';

Constructor

`new`

constructor(backend: SaveBackend, timer?: SaveTimer, options?: RemoteSaveOptions)

Parameter	Type	Description
`backend`	`SaveBackend`
`timer?`	`SaveTimer`
`options?`	`RemoteSaveOptions`

Accessors

Name	Type	Description
`loaded`get	`boolean`	Whether `load` has completed, either way.
`status`get	`SaveStatus`
`pending`get	`number`	How many keys are waiting to be sent, counting a batch that failed and came back.
`lastError`get	`string \| null`	The last failure's message, cleared by the next batch that lands.

Methods

`load`

load(): Promise<boolean>

Fill the cache from the backend. Await this before the first frame.

Answers whether it worked rather than rejecting, because a rejected promise nobody caught is an unhandled rejection during boot and a store that cannot load is a store that still has to serve defaults. A failure also says so on the console once: a consumer that ignores both the answer and the status boots on defaults and overwrites the player's real settings with them on the first write, which is the one outcome worse than not loading.

`onStatusChange`

onStatusChange(listener: (status: SaveStatus) => void): () => void

Told when the status changes, and only when it changes. Returns the unsubscribe.

Parameter	Type	Description
`listener`	`(status: SaveStatus) => void`

`read`

read(key: string): string | null

Parameter	Type	Description
`key`	`string`

`write`

write(key: string, value: string): void

Parameter	Type	Description
`key`	`string`
`value`	`string`

`remove`

remove(key: string): void

Parameter	Type	Description
`key`	`string`

`flush`

flush(): Promise<void>

Send everything queued now, and resolve when that attempt has settled.

For a consumer leaving the page. It never rejects: read status afterwards to find out whether it landed. A batch already in flight is awaited first, so two flushes cannot overlap.

`discardPending`

discardPending(): void

Throw away everything waiting to be sent.

The escape hatch that makes "a failed batch is kept forever" acceptable: a consumer that has decided the queue is stale — a player signing out, a save slot deleted — says so, rather than this store guessing after some number of failures. The cache is untouched, so reads still answer what the session wrote.