Skip to main content

Interface: ReplicacheOptions<MD>#

The options passed to Replicache.

Type parameters#

NameType
MDMutatorDefs

Properties#

logLevel#

Optional logLevel: LogLevel

Determines how much logging to do. When this is set to 'debug', Replicache will also log 'info' and 'error' messages. When set to 'info' we log 'info' and 'error' but not 'debug'. When set to 'error' we only log 'error' messages.

Defined in: replicache.ts:157


mutators#

Optional mutators: MD

An object used as a map to define the mutators. These gets registered at startup of Replicache.

Mutators are used to make changes to the data.

Example#

The registered mutations are reflected on the mutate property of the Replicache instance.

const rep = new Replicache({
mutators: {
async createTodo(tx: WriteTransaction, args: JSONValue) {
const key = `/todo/${args.id}`;
if (await tx.has(key)) {
throw new Error('Todo already exists');
}
await tx.put(key, args);
},
async deleteTodo(tx: WriteTransaction, id: number) {
...
},
},
});

This will create the function to later use:

await rep.mutate.createTodo({
id: 1234,
title: 'Make things work offline',
complete: true,
});

Replays#

Mutators run once when they are initially invoked, but they might also be replayed multiple times during sync. As such mutators should not modify application state directly. Also, it is important that the set of registered mutator names only grows over time. If Replicache syncs and needed mutator is not registered, it will substitute a no-op mutator, but this might be a poor user experience.

Server application#

During push, a description of each mutation is sent to the server's push endpoint where it is applied. Once the mutation has been applied successfully, as indicated by the client view's lastMutationId field, the local version of the mutation is removed. See the design doc for additional details on the sync protocol.

Transactionality#

Mutators are atomic: all their changes are applied together, or none are. Throwing an exception aborts the transaction. Otherwise, it is committed. As with query and subscribe all reads will see a consistent view of the cache while they run.

Defined in: replicache.ts:225


name#

Optional name: string

The name of the Replicache database. This defaults to "default".

You can use multiple Replicache instances as long as the names are unique.

Using different names for different users allows you to switch users even when you are offline.

Defined in: replicache.ts:100


pullAuth#

Optional pullAuth: string

This is the authentication token used when doing a pull .

Defined in: replicache.ts:82


pullInterval#

Optional pullInterval: null | number

The duration between each pull. Set this to null to prevent pulling in the background.

Defined in: replicache.ts:113


pullURL#

Optional pullURL: string

This is the URL to the server endpoint dealing with pull. See Server Setup Downstream Sync for more details.

Defined in: replicache.ts:90


pushAuth#

Optional pushAuth: string

This is the authentication token used when doing a push .

Defined in: replicache.ts:67


pushDelay#

Optional pushDelay: number

The delay between when a change is made to Replicache and when Replicache attempts to push that change.

Defined in: replicache.ts:119


pushURL#

Optional pushURL: string

This is the URL to the server endpoint dealing with the push updates. See Server Setup Upstream Sync for more details.

Defined in: replicache.ts:74


schemaVersion#

Optional schemaVersion: string

The schema version of the data understood by this application. This enables versioning of mutators (in the push direction) and the client view (in the pull direction).

Defined in: replicache.ts:107


useMemstore#

Optional useMemstore: boolean

Allows using an in memory store instead of IndexedDB. This is useful for testing for example. Notice that when this is true no data is persisted in Replicache and all the data that has not yet been synced when Replicache is closed or the page is unloaded is lost.

Defined in: replicache.ts:149


wasmModule#

Optional wasmModule: InitInput

By default we will load the Replicache wasm module relative to the Replicache js files but under some circumstances (like bundling with old versions of Webpack) it is useful to manually configure where the wasm module is located on the web server.

If you provide your own path to the wasm module it probably makes sense to use a relative URL relative to your current file.

wasmModule: new URL('./relative/path/to/replicache.wasm', import.meta.url),

You might also want to consider using an absolute URL so that we can find the wasm module no matter where your js file is loaded from:

wasmModule: '/static/replicache.wasm',

Defined in: replicache.ts:141