Skip to main content

Interface: ReplicacheOptions<MD>

The options passed to Replicache.

Type parameters#

NameType
MDextends MutatorDefs

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.


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.


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.


pullAuth#

Optional pullAuth: string

This is the authorization token used when doing a pull.


pullInterval#

Optional pullInterval: null | number

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


pullURL#

Optional pullURL: string

This is the URL to the server endpoint dealing with pull. See Pull Endpoint Reference for more details.


puller#

Optional puller: Puller

Allows passing in a custom implementation of a Puller function. This function is called when doing a pull and it is responsible for communicating with the server.

Normally, this is just a POST to a URL with a JSON body but you can provide your own function if you need to do things differently.


pushAuth#

Optional pushAuth: string

This is the authorization token used when doing a push.


pushDelay#

Optional pushDelay: number

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


pushURL#

Optional pushURL: string

This is the URL to the server endpoint dealing with the push updates. See Push Endpoint Reference for more details.


pusher#

Optional pusher: Pusher

Allows passing in a custom implementation of a Pusher function. This function is called when doing a push and it is responsible for communicating with the server.

Normally, this is just a POST to a URL with a JSON body but you can provide your own function if you need to do things differently.


requestOptions#

Optional requestOptions: RequestOptions

Options to use when doing pull and push requests.


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


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.


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',