Zero class is the primary client for Zero. It manages connections, queries, mutations, and real-time synchronization with your database.
Constructor
Configuration object for the Zero client
ZeroOptions
A unique identifier for the user. Must be non-empty. Each userID gets its own client-side storage.
This must match the
sub claim of the auth token if auth is provided.The schema defining the tables and their relationships used in Zero.
URL to the zero-cache server. Can be:
- A simple hostname:
"https://myapp.zero.ms" - A prefix with a single path component:
"https://myapp.zero.ms/zero"
A token to identify and authenticate the user. Set to
null or undefined if there is no logged in user.When auth changes while connected, Zero refreshes server-side auth context and re-transforms queries without reconnecting.When a 401 or 403 HTTP status code is received, Zero will transition to the needs-auth connection state.Distinguishes the storage used by this Zero instance from other instances with the same userID.
Custom mutator definitions. Client-side mutators must be idempotent as they can be rebased multiple times.Define mutators using
defineMutator to create type-safe mutations:Custom URL for mutation requests sent to your API server.
Custom headers to include in mutation requests sent to your API server.
Custom URL for query requests sent to your API server.
Custom headers to include in query requests sent to your API server.
Determines the level of detail for logging. Messages are logged to the console.
Storage implementation to use on the client:
'idb': IndexedDB storage (default) - persists data between sessions'mem': In-memory storage - data is not persisted- Custom function to create KV stores
Milliseconds to wait before disconnecting a Zero instance whose tab has become hidden. Default is 5 minutes.
Milliseconds to wait before disconnecting when the connection has timed out. Default is 1 minute.
Timeout in milliseconds for ping operations. Controls both idle time before sending a ping and wait time for pong response.
Total time to detect a dead connection is 2 × pingTimeoutMs.
Integrates UI framework batching with Zero (e.g., React’s
unstable_batchedUpdates or Solid’s batch).
Implementations must call applyViewUpdates synchronously.Milliseconds to wait before sending the next batch of query changes to the server.
Milliseconds to wait for a materialization to complete before printing a warning to the console.
Called when a client code update is needed. Default behavior is to reload the page.
Provide your own function to prevent automatic reloading (e.g., display a toast notification).
Called when the client can no longer sync due to missing synchronization state.
Default behavior is to reload the page.
Context passed to queries when they are executed.
Properties
The version of the Zero client.
The user ID for this Zero instance.
The storage key for this Zero instance.
The unique client ID for this instance of Zero.
The server URL that this Zero instance is configured with.
The name of the IndexedDB database in which the data of this instance is stored.
The schema version of the data understood by this application.
The schema passed into Zero when it was constructed.Can be paired with the inspector API to explore the client cache:
Whether this Zero instance has been closed. Once closed, it no longer syncs and cannot be used for queries or mutations.
The connection API for managing Zero’s connection lifecycle.
Execute mutations. Call with registered custom mutators:When
schema.enableLegacyMutators is true, legacy conveniences are added:- Table-scoped CRUD helpers:
z.mutate.issue.create/update/delete - Custom mutators exposed directly on
z.mutate
Batch multiple CRUD mutations together:All mutations in a batch are sent in a single transaction. If one fails, all are rolled back.Deprecated: Use
z.mutate(mutationRequest) instead.Query builders for each table in the schema.Deprecated: Use
createBuilder() to create query builders instead.The context passed to queries when they are executed.
Methods
run()
Executes a query once and returns the results.The query to execute
Options controlling query execution:
{type: 'complete'}: Wait for server sync (default){type: 'unknown'}: Run immediately with local data
A promise resolving to the query results
materialize()
Creates a materialized view of a query that stays synchronized with the database.The query to materialize
Optional factory function to create a custom view implementation
Options controlling view behavior
A TypedView that stays synchronized with the data, or a custom view if factory is provided
preload()
Preloads data for a query into the cache without keeping it in memory.The query to preload
Options controlling preload behavior
An object with:
complete: Promise that resolves when data is loadedcleanup: Function to cancel the preload
close()
Closes this Zero instance.- No longer syncs with the server
- Cannot query or mutate data
- Query views stop updating
A promise that resolves when the instance is closed