Loading...
// ---cut---
const useAppStore = () =>
useStore({
storeId: 'otel-demo',
schema,
adapter,
batchUpdates,
otelOptions: { tracer },
})
export const App: FC = () => {
const [storeRegistry] = useState(() => new StoreRegistry())
return (
{/* Your app content */}
}
```
### `reference/framework-integrations/react/schema.ts`
```ts filename="reference/framework-integrations/react/schema.ts"
export const tables = {
todos: State.SQLite.table({
name: 'todos',
columns: {
id: State.SQLite.text({ primaryKey: true }),
text: State.SQLite.text(),
completed: State.SQLite.boolean({ default: false }),
createdAt: State.SQLite.datetime(),
},
}),
uiState: State.SQLite.clientDocument({
name: 'UiState',
schema: Schema.Struct({
newTodoText: Schema.String,
filter: Schema.Literal('all', 'active', 'completed'),
}),
default: { id: SessionIdSymbol, value: { newTodoText: '', filter: 'all' } },
}),
} as const
export const events = {
todoCreated: Events.synced({
name: 'v1.TodoCreated',
schema: Schema.Struct({ id: Schema.String, text: Schema.String, createdAt: Schema.Date }),
}),
} as const
const materializers = State.SQLite.materializers(events, {
[events.todoCreated.name]: defineMaterializer(events.todoCreated, ({ id, text, createdAt }) =>
tables.todos.insert({ id, text, completed: false, createdAt }),
),
})
const state = State.SQLite.makeState({ tables, materializers })
export const schema = makeSchema({ events, state })
```
### `reference/opentelemetry/schema.ts`
```ts filename="reference/opentelemetry/schema.ts"
export { schema } from '../framework-integrations/react/schema.ts'
```
{todos.length} items
}
```
### `reference/framework-integrations/react/store.ts`
```ts filename="reference/framework-integrations/react/store.ts"
const adapter = makeInMemoryAdapter()
export const useAppStore = () =>
useStore({
storeId: 'app-root',
schema,
adapter,
batchUpdates,
})
```
#### Solid
## `reference/reactivity-system/solid-component.tsx`
```tsx filename="reference/reactivity-system/solid-component.tsx"
declare const store: Store & { useQuery: {value()}
}
```
### Reacting to changing variables passed to queries
If your query depends on a variable passed in by the component, use the deps array to react to changes in this variable.
## `reference/reactivity-system/deps-query.tsx`
```tsx filename="reference/reactivity-system/deps-query.tsx"
export const todos$ = ({ showCompleted }: { showCompleted: boolean }) =>
queryDb(
() => {
return tables.todos.where(showCompleted === true ? { completed: true } : {})
},
{
label: 'todos$',
deps: [showCompleted === true ? 'true' : 'false'],
},
)
export const MyComponent: FC<{ showCompleted: boolean }> = ({ showCompleted }) => {
const store = useAppStore()
const todos = store.useQuery(todos$({ showCompleted })) as ReadonlyArray<{
id: string
text: string
completed: boolean
}>
return {todos.length} Done
}
```
## Further reading
- [Riffle](https://riffle.systems/essays/prelude/): Building data-centric apps with a reactive relational database
- [Adapton](http://adapton.org/) / [miniAdapton](https://arxiv.org/pdf/1609.05337)
## Related technologies
- [Signia](https://signia.tldraw.dev/): Signia is a minimal, fast, and scalable signals library for TypeScript developed by TLDraw.
# [Rules for AI agents](https://main--livestore-docs-dev.netlify.app/building-with-livestore/rules-for-ai-agents/)
## AGENTS.md
Add the content of this `AGENTS.md` file or other custom rules:
```md wrap
- When you need to look up information about LiveStore, always use the `docs` directory that's shipped as part of the `@livestore/livestore` package in `node_modules/@livestore/livestore/docs`.
```
# [Materializers](https://main--livestore-docs-dev.netlify.app/building-with-livestore/state/materializers/)
Materializers are functions that allow you to write to your database in response to events. Materializers are executed in the order of the events in the eventlog.
## Example
## `reference/state/materializers/example.ts`
```ts filename="reference/state/materializers/example.ts"
export const todos = State.SQLite.table({
name: 'todos',
columns: {
id: State.SQLite.text({ primaryKey: true }),
text: State.SQLite.text(),
completed: State.SQLite.boolean({ default: false }),
previousIds: State.SQLite.json({
schema: Schema.Array(Schema.String),
nullable: true,
}),
},
})
export const table1 = State.SQLite.table({
name: 'settings',
columns: {
id: State.SQLite.text({ primaryKey: true }),
someVal: State.SQLite.integer({ default: 0 }),
},
})
export const table2 = State.SQLite.table({
name: 'preferences',
columns: {
id: State.SQLite.text({ primaryKey: true }),
otherVal: State.SQLite.text({ default: 'default' }),
},
})
export const events = {
todoCreated: Events.synced({
name: 'todoCreated',
schema: Schema.Struct({
id: Schema.String,
text: Schema.String,
completed: Schema.Boolean.pipe(Schema.optional),
}),
}),
userPreferencesUpdated: Events.synced({
name: 'userPreferencesUpdated',
schema: Schema.Struct({ userId: Schema.String, theme: Schema.String }),
}),
factoryResetApplied: Events.synced({
name: 'factoryResetApplied',
schema: Schema.Struct({}),
}),
} as const
export const materializers = State.SQLite.materializers(events, {
[events.todoCreated.name]: defineMaterializer(events.todoCreated, ({ id, text, completed }) =>
todos.insert({ id, text, completed: completed ?? false }),
),
[events.userPreferencesUpdated.name]: defineMaterializer(events.userPreferencesUpdated, ({ userId, theme }) => {
console.log(`User ${userId} updated theme to ${theme}.`)
return []
}),
[events.factoryResetApplied.name]: defineMaterializer(events.factoryResetApplied, () => [
table1.update({ someVal: 0 }),
table2.update({ otherVal: 'default' }),
// Raw SQL is also supported via { sql, bindValues }
{ sql: 'DELETE FROM todos', bindValues: {} },
]),
})
```
## Reading from the database in materializers
Sometimes it can be useful to query your current state when executing a materializer. This can be done by using `ctx.query` in your materializer function.
## `reference/state/materializers/with-query.ts`
```ts filename="reference/state/materializers/with-query.ts"
const events = {
todoCreated: Events.synced({
name: 'todoCreated',
schema: Schema.Struct({
id: Schema.String,
text: Schema.String,
completed: Schema.Boolean.pipe(Schema.optional),
}),
}),
} as const
export const materializers = State.SQLite.materializers(events, {
[events.todoCreated.name]: defineMaterializer(events.todoCreated, ({ id, text, completed }, ctx) => {
const previousIds = ctx.query(todos.select('id'))
// ctx.query also supports raw SQL via { query, bindValues }
const existingTodos = ctx.query({ query: 'SELECT id FROM todos', bindValues: {} })
return todos.insert({ id: `${existingTodos.length}-${id}`, text, completed: completed ?? false, previousIds })
}),
})
```
## Transactional behaviour
A materializer is always executed in a transaction. This transaction applies to:
- All database write operations returned by the materializer.
- Any `ctx.query` calls made within the materializer, ensuring a consistent view of the data.
Materializers can return:
- A single database write operation.
- An array of database write operations.
- `void` (i.e., no return value) if no database modifications are needed.
- An `Effect` that resolves to one of the above (e.g., `Effect.succeed(writeOp)` or `Effect.void`).
The `context` object passed to each materializer provides `query` for database reads and `event` for the full event details.
## Error handling
If a materializer function throws an error, or if an `Effect` returned by a materializer fails, the entire transaction for that event will be rolled back. This means any database changes attempted by that materializer for the failing event will not be persisted. The error will be logged, and the system will typically halt or flag the event as problematic, depending on the specific LiveStore setup.
If the error happens on the client which tries to commit the event, the event will never be committed and pushed to the sync backend.
In the future there will be ways to configure the error-handling behaviour, e.g. to allow skipping an incoming event when a materializer fails in order to avoid the app getting stuck. However, skipping events might also lead to diverging state across clients and should be used with caution.
## Best practices
### Side-effect free / deterministic
It's strongly recommended to make sure your materializers are side-effect free and deterministic. This also implies passing in all necessary data via the event payload.
Example:
## `reference/state/materializers/deterministic.ts`
```ts filename="reference/state/materializers/deterministic.ts"
declare const store: Store
export const nondeterministicEvents = {
todoCreated: Events.synced({
name: 'v1.TodoCreated',
schema: Schema.Struct({ text: Schema.String }),
}),
} as const
export const nondeterministicMaterializers = State.SQLite.materializers(nondeterministicEvents, {
[nondeterministicEvents.todoCreated.name]: defineMaterializer(nondeterministicEvents.todoCreated, ({ text }) =>
todos.insert({ id: randomUUID(), text }),
),
})
store.commit(nondeterministicEvents.todoCreated({ text: 'Buy groceries' }))
export const deterministicEvents = {
todoCreated: Events.synced({
name: 'v1.TodoCreated',
schema: Schema.Struct({ id: Schema.String, text: Schema.String }),
}),
} as const
export const deterministicMaterializers = State.SQLite.materializers(deterministicEvents, {
[deterministicEvents.todoCreated.name]: defineMaterializer(deterministicEvents.todoCreated, ({ id, text }) =>
todos.insert({ id, text }),
),
})
store.commit(deterministicEvents.todoCreated({ id: nanoid(), text: 'Buy groceries' }))
```
# [SQL queries](https://main--livestore-docs-dev.netlify.app/building-with-livestore/state/sql-queries/)
## Query builder
LiveStore also provides a small query builder for the most common queries. The query builder automatically derives the appropriate result schema internally.
## `reference/state/sql-queries/query-builder.ts`
```ts filename="reference/state/sql-queries/query-builder.ts"
const table = State.SQLite.table({
name: 'my_table',
columns: {
id: State.SQLite.text({ primaryKey: true }),
name: State.SQLite.text(),
tags: State.SQLite.json({ schema: Schema.Array(Schema.String), default: [] }),
},
})
// Read queries
table.select('name')
table.where('name', '=', 'Alice')
table.where({ name: 'Alice' })
table.orderBy('name', 'desc').offset(10).limit(10)
table.count().where('name', 'LIKE', '%Ali%')
// JSON array containment queries
// NOTE: These use SQLite's json_each() which cannot be indexed
table.where({ tags: { op: 'JSON_CONTAINS', value: 'important' } })
table.where({ tags: { op: 'JSON_NOT_CONTAINS', value: 'archived' } })
// Write queries
table.insert({ id: '123', name: 'Bob' })
table.update({ name: 'Alice' }).where({ id: '123' })
table.delete().where({ id: '123' })
// Upserts (insert or update on conflict)
table.insert({ id: '123', name: 'Charlie' }).onConflict('id', 'replace')
table.insert({ id: '456', name: 'Diana' }).onConflict('id', 'update', { name: 'Diana Updated' })
```
## Raw SQL queries
LiveStore supports arbitrary SQL queries on top of SQLite. In order for LiveStore to handle the query results correctly, you need to provide the result schema.
## `reference/state/sql-queries/raw-sql.ts`
```ts filename="reference/state/sql-queries/raw-sql.ts"
// ---cut---
const table = State.SQLite.table({
name: 'my_table',
columns: {
id: State.SQLite.text({ primaryKey: true }),
name: State.SQLite.text(),
},
})
const filtered$ = queryDb({
query: sql`select * from my_table where name = 'Alice'`,
schema: Schema.Array(table.rowSchema),
})
const count$ = queryDb({
query: sql`select count(*) as count from my_table`,
schema: Schema.Struct({ count: Schema.Number }).pipe(Schema.pluck('count'), Schema.Array, Schema.headOrElse()),
})
```
## JSON array containment
For JSON array columns, you can use `JSON_CONTAINS` and `JSON_NOT_CONTAINS` operators to check if an array contains (or doesn't contain) a specific value:
```ts
// Find items with a specific tag
table.where({ tags: { op: 'JSON_CONTAINS', value: 'important' } })
// Find items without a specific tag
table.where({ tags: { op: 'JSON_NOT_CONTAINS', value: 'archived' } })
```
:::caution[Performance consideration]
These operators use SQLite's `json_each()` table-valued function which **cannot be indexed** and requires a full table scan. For large tables with frequent lookups, consider denormalizing the data into a separate indexed table.
:::
## Best practices
- Query results should be treated as immutable/read-only
- For queries which could return many rows, it's recommended to paginate the results
- Usually both via paginated/virtualized rendering as well as paginated queries
- You'll get best query performance by using a `WHERE` clause over an indexed column combined with a `LIMIT` clause. Avoid `OFFSET` as it can be slow on large tables
- For very large/complex queries, it can also make sense to implement incremental view maintenance (IVM) for your queries
- You can for example do this by have a separate table which is a materialized version of your query results which you update manually (and ideally incrementally) as the underlying data changes.
# [SQLite in LiveStore](https://main--livestore-docs-dev.netlify.app/building-with-livestore/state/sqlite/)
LiveStore heavily uses SQLite as its default state/read model.
## Implementation notes
- LiveStore relies on the following SQLite extensions to be available: `-DSQLITE_ENABLE_BYTECODE_VTAB -DSQLITE_ENABLE_SESSION -DSQLITE_ENABLE_PREUPDATE_HOOK`
- [bytecode](https://www.sqlite.org/bytecodevtab.html)
- [session](https://www.sqlite.org/sessionintro.html) (incl. preupdate)
- For web / node adapter:
- LiveStore uses [a fork](https://github.com/livestorejs/wa-sqlite) of the [wa-sqlite](https://github.com/rhashimoto/wa-sqlite) SQLite WASM library.
- Write‑ahead logging (WAL) is currently not supported/enabled for the web adapter using OPFS (AccessHandlePoolVFS). The underlying VFS does not support WAL reliably in this setup; we disable it until it’s safe to use. See our tracking issue and upstream notes:
- LiveStore: https://github.com/livestorejs/livestore/issues/258
- wa‑sqlite examples (comparison table shows WAL unsupported for AccessHandlePoolVFS): https://github.com/rhashimoto/wa-sqlite/blob/master/src/examples/README.md
- Related discussion on single‑connection OPFS and locking: https://github.com/rhashimoto/wa-sqlite/discussions/81
- In the future LiveStore might use a non‑WASM build for Node/Bun/Deno/etc.
- For Expo adapter:
- LiveStore uses the official expo-sqlite library which supports LiveStore's SQLite requirements.
- LiveStore uses the `session` extension to enable efficient database rollback which is needed when the eventlog is rolled back as part of a rebase. An alternative implementation strategy would be to rely on snapshotting (i.e. periodically create database snapshots and roll back to the latest snapshot + applied missing mutations).
## Default tables
LiveStore operates two SQLite databases by default: a state database (your materialized tables) and an event log database (the immutable event stream and sync metadata). In addition to your own application tables, LiveStore creates a small set of internal tables in each database.
### State database
- `__livestore_schema`
- Tracks the schema hash and last update time per materialized table. Used for migrations and compatibility checks.
- `__livestore_schema_event_defs`
- Tracks the schema hash and last update time per event definition. Used to detect incompatible event schema changes during rematerialization.
- `__livestore_session_changeset`
- Stores SQLite session changeset blobs keyed by event sequence numbers. Used to efficiently roll back and re‑apply state during rebases.
- Your application tables
- All tables you define via `State.SQLite.table(...)` live in the state database.
### Eventlog database
- `eventlog`
- Append‑only table containing all events (sequence numbers, parent links, event name, encoded args, client/session IDs, schema hash, optional sync metadata). Used to reconstruct state and for sync.
- `__livestore_sync_status`
- Stores the current head and optional backend identity for synchronization bookkeeping.
Note: The event log database’s use of SQLite is an implementation detail. It is not a public interface and is not intended for direct reads or writes. Query state via your materialized tables and LiveStore APIs; do not depend on the event log database layout or mutate it directly.
# [SQLite state schema](https://main--livestore-docs-dev.netlify.app/building-with-livestore/state/sqlite-schema/)
LiveStore provides a schema definition language for defining your database tables and mutation definitions using explicit column configurations. LiveStore automatically migrates your database schema when you change your schema definitions.
> **Alternative Approach**: You can also define tables using [Effect Schema with annotations](/building-with-livestore/state/sqlite-schema-effect) for type-safe schema definitions.
### Example
{issue?.title}
}
```
### `reference/framework-integrations/react/issue.schema.ts`
```ts filename="reference/framework-integrations/react/issue.schema.ts"
// Event definitions
export const events = {
issueCreated: Events.synced({
name: 'v1.IssueCreated',
schema: Schema.Struct({
id: Schema.String,
title: Schema.String,
status: Schema.Literal('todo', 'done'),
}),
}),
issueStatusChanged: Events.synced({
name: 'v1.IssueStatusChanged',
schema: Schema.Struct({
id: Schema.String,
status: Schema.Literal('todo', 'done'),
}),
}),
}
// State definition
export const tables = {
issue: State.SQLite.table({
name: 'issue',
columns: {
id: State.SQLite.text({ primaryKey: true }),
title: State.SQLite.text(),
status: State.SQLite.text(),
},
}),
}
const materializers = State.SQLite.materializers(events, {
'v1.IssueCreated': ({ id, title, status }) => tables.issue.insert({ id, title, status }),
'v1.IssueStatusChanged': ({ id, status }) => tables.issue.update({ status }).where({ id }),
})
const state = State.SQLite.makeState({ tables, materializers })
export const schema = makeSchema({ events, state })
```
## Setting Up
### 1. Configure the Store
Create a store configuration file that exports a custom hook wrapping [`useStore()`](#usestoreoptions):
The [`useStore()`](#usestoreoptions) hook accepts store configuration options and returns a store instance. It suspends while the store is loading, so components using it need to be wrapped in a `Suspense` boundary.
### 2. Set Up the Registry
Create a [`StoreRegistry`](#new-storeregistryconfig) and provide it via [`Something went wrong
const appLoadingFallback = Loading LiveStore...
export const App = ({ children }: { children: ReactNode }) => {
const [storeRegistry] = useState(() => new StoreRegistry({ defaultOptions: { batchUpdates } }))
return (
...
}
```
## Querying Data
Use [`store.useQuery()`](#storeusequeryqueryable) to subscribe to reactive queries:
## `reference/framework-integrations/react/use-query.tsx`
```tsx filename="reference/framework-integrations/react/use-query.tsx"
const query$ = queryDb(tables.todos.where({ completed: true }).orderBy('id', 'desc'), {
label: 'completedTodos',
})
export const CompletedTodos: FC = () => {
const store = useAppStore()
const todos = store.useQuery(query$)
return (
{todos.map((todo) => (
)
}
```
## Client Documents
Use [`store.useClientDocument()`](#storeuseclientdocumenttable-id-options) for client-specific state:
## `reference/framework-integrations/react/use-client-document.tsx`
```tsx filename="reference/framework-integrations/react/use-client-document.tsx"
export const TodoItem: FC<{ id: string }> = ({ id }) => {
const store = useAppStore()
const [todo, updateTodo] = store.useClientDocument(tables.uiState, id)
const handleClick = useCallback(() => {
updateTodo({ newTodoText: 'Hello, world!' })
}, [updateTodo])
return (
)
}
```
## Advanced Patterns
### Multiple Stores
You can have multiple stores within a single React application. This is useful for:
- **Partial data synchronization** - Load only the data you need, when you need it
- **Multi-tenant applications** - Separate stores for each workspace, organization, or team (like Slack workspaces or Linear teams)
Use the [`storeOptions()`](#storeoptionsoptions) helper for type-safe, reusable configurations, and then create multiple instances for the same store configuration by using different `storeId` values:
## `reference/framework-integrations/react/issue.store.ts`
```ts filename="reference/framework-integrations/react/issue.store.ts"
// Define reusable store configuration with storeOptions()
// This helper provides type safety and can be reused across your app
export const issueStoreOptions = (issueId: string) =>
storeOptions({
storeId: `issue-${issueId}`,
schema,
adapter: makeInMemoryAdapter(),
})
```
## `reference/framework-integrations/react/IssueView.tsx`
```tsx filename="reference/framework-integrations/react/IssueView.tsx"
const issueErrorFallback = {todo.text}
))}
Error loading issue
const issueLoadingFallback = Loading issue...
export const IssueView = ({ issueId }: { issueId: string }) => {
// useStore() suspends the component until the store is loaded
// If the same store was already loaded, it returns immediately
const issueStore = useStore(issueStoreOptions(issueId))
// Query data from the store
const [issue] = issueStore.useQuery(queryDb(tables.issue.select().where({ id: issueId })))
if (issue == null) return Issue not found
return (
{issue.title}
Status: {issue.status}
Error loading issue
const preloadedIssueLoadingFallback = Loading issue...
export const PreloadedIssue = ({ issueId }: { issueId: string }) => {
const [showIssue, setShowIssue] = useState(false)
const storeRegistry = useStoreRegistry()
// Preload the store when the user hovers (before they click)
const handleMouseEnter = useCallback(() => {
storeRegistry.preload({
...issueStoreOptions(issueId),
unusedCacheTime: 10_000, // Optionally override options
})
}, [issueId, storeRegistry])
const handleClick = useCallback(() => {
setShowIssue(true)
}, [])
return (
{showIssue == null ? (
) : (
)}
)
}
```
### StoreId Guidelines
When creating `storeId` values:
- **Valid characters** - Only alphanumeric characters, underscores (`_`), and hyphens (`-`) are allowed (regex: `/^[a-zA-Z0-9_-]+$/`)
- **Globally unique** - Prefer globally unique IDs (e.g., nanoid) to prevent collisions
- **Use namespaces** - Prefix with the entity type (e.g., `workspace-abc123`, `issue-456`) to avoid collisions and easier identification when debugging
- **Keep them stable** - The same entity should always use the same `storeId` across renders
- **Sanitize user input** - If incorporating user data, validate/sanitize to prevent injection attacks
- **Document your conventions** - Document special IDs like `user-current` as they're part of your API contract
### Logging
You can customize the logger and log level for debugging:
## `reference/framework-integrations/react/store-with-logging.ts`
```ts filename="reference/framework-integrations/react/store-with-logging.ts"
const adapter = makeInMemoryAdapter()
// ---cut---
export const useAppStore = () =>
useStore({
storeId: 'app-root',
schema,
adapter,
batchUpdates,
// Optional: swap the logger implementation
logger: Logger.prettyWithThread('app'),
// Optional: set minimum log level (use LogLevel.None to disable)
logLevel: LogLevel.Info,
})
```
Use `LogLevel.None` to disable logging entirely.
## API Reference
### `storeOptions(options)`
Helper for defining reusable store options with full type inference. Returns options that can be passed to [`useStore()`](#usestoreoptions) or [`storeRegistry.preload()`](#storeregistrypreloadoptions).
Options:
- `storeId` - Unique identifier for this store instance
- `schema` - The LiveStore schema
- `adapter` - The platform adapter
- `unusedCacheTime?` - Time in ms to keep this store in cache after it becomes unused (default: `60_000` in browser, `Infinity` in non-browser environments). Overrides the registry-level default when set.
- `batchUpdates?` - Function for batching React updates (recommended)
- `boot?` - Function called when the store is loaded
- `onBootStatus?` - Callback for boot status updates
- `context?` - User-defined context for dependency injection
- `syncPayload?` - Payload sent to sync backend (e.g., auth tokens)
- `syncPayloadSchema?` - Schema for type-safe sync payload validation
- `confirmUnsavedChanges?` - Register beforeunload handler (default: `true`, web only)
- `logger?` - Custom logger implementation
- `logLevel?` - Log level (e.g., `LogLevel.Info`, `LogLevel.Debug`, `LogLevel.None`)
- `otelOptions?` - OpenTelemetry configuration (`{ tracer, rootSpanContext }`)
- `disableDevtools?` - Whether to disable devtools (`boolean | 'auto'`, default: `'auto'`)
- `debug?` - Debug options (`{ instanceId?: string }`)
### `useStore(options)`
Returns a store instance augmented with hooks ([`store.useQuery()`](#storeusequeryqueryable) and [`store.useClientDocument()`](#storeuseclientdocumenttable-id-options)) for reactive queries.
- Suspends until the store is loaded.
- Throws an error if loading fails.
- Store gets cached by its `storeId` in the [`StoreRegistry`](#new-storeregistryconfig). Multiple calls with the same `storeId` return the same store instance.
- Store is cached as long as it's being used, and after `unusedCacheTime` expires (default `60_000` ms in browser, `Infinity` in non-browser)
- Default store options can be configured in [`StoreRegistry`](#new-storeregistryconfig) constructor.
- Store options are only applied when the store is loaded. Subsequent calls with different options will not affect the store if it's already loaded and cached in the registry.
### `store.commit(...events)` / `store.commit(txnFn)`
Commits events to the store. Supports multiple calling patterns:
- `store.commit(...events)` - Commit one or more events
- `store.commit(txnFn)` - Commit events via a transaction function
- `store.commit(options, ...events)` - Commit with options
- `store.commit(options, txnFn)` - Options with transaction function
Options:
- `skipRefresh` - Skip refreshing reactive queries after commit (advanced)
### `store.useQuery(queryable)`
Subscribes to a reactive query. Re-renders the component when the result changes.
- Takes any `Queryable`: `QueryBuilder`, `LiveQueryDef`, `SignalDef`, or `LiveQuery` instance
- Returns the query result
### `store.useClientDocument(table, id?, options?)`
React.useState-like hook for client-document tables.
- Returns `[row, setRow, id, query$]` tuple
- Works only with tables defined via `State.SQLite.clientDocument()`
- If the table has a default id, the `id` argument is optional
### `store.useSyncStatus()`
React hook that subscribes to sync status changes. Re-renders the component when sync status changes.
```tsx
function SyncIndicator() {
const store = useStore(storeOptions)
const status = store.useSyncStatus()
return {status.isSynced ? '✓ Synced' : `Syncing (${status.pendingCount} pending)...`}
}
```
For the `SyncStatus` type and non-React APIs (`syncStatus()`, `subscribeSyncStatus()`, `syncStatusStream()`), see the [Store documentation](/building-with-livestore/store#sync-status).
### `new StoreRegistry(config?)`
Creates a registry that coordinates store loading, caching, and retention.
Config:
- `defaultOptions?` - Default options that are applied to all stores when they are loaded.:
- `batchUpdates?` - Function for batching React updates
- `unusedCacheTime?` - Cache time for unused stores
- `disableDevtools?` - Whether to disable devtools
- `confirmUnsavedChanges?` - beforeunload confirmation
- `otelOptions?` - OpenTelemetry configuration
- `debug?` - Debug options
- `runtime?` - Effect runtime for registry operations
### `-
{#each store.query(todos$) as todo (todo.id)}
- {todo.text} {/each}
Loading LiveStore...
- {{ todo.text }}
Loading app...
export const App: React.FC = () => {
const [storeRegistry] = useState(() => new StoreRegistry())
return (
{/* Your app components go here */}
TodoMVC
-
{visibleTodos.map((todo) => (
-
Loading LiveStore...
- {{ todo.text }}
| Dark PNG | Dark SVG | Light PNG | Light SVG |
|---|---|---|---|
|
|
|
|
UX
- Synced: Real-time updates across devices
- Fast: No async loading over the network
- Persistent: Works offline, survives page refresh
DX
- Principled: Event-driven instead of mutable state
- Composable & Type-safe: Fully typed events & queries
- Reactive: Automatic UI updates when data changes
AX
- Testable: Immutable eventlog for feedback loop
- Debuggable: Same events always produce same state
- Evolvable: Reset & fork state for experiments
Are you an expert? See here for advanced topics.
- [How LiveStore deals with merge conflicts?](/overview/how-livestore-works#conflict-resolution) - Why event-sourcing instead of CRDTs or query-driven sync? - How do schema migrations work? - What are limitations of LiveStore? - How LiveStore is perfect for coding agents.
```d2
...@../../../../src/content/base.d2
direction: right
"User action": {
label: "User action"
shape: rectangle
}
Event: {
label: "Event"
shape: rectangle
}
Eventlog: {
label: "Eventlog"
shape: rectangle
}
"SQLite state": {
label: "SQLite state"
shape: rectangle
}
UI: {
label: "UI"
shape: rectangle
}
"Sync to other clients": {
label: "Sync to other clients"
shape: rectangle
}
"User action" -> Event -> Eventlog -> "SQLite state" -> UI
Eventlog -> "Sync to other clients"
```
Instead of mutating state directly, you commit **events** that _describe_ what happened. These events are persisted to an **eventlog** (like a git history) and automatically materialized into a local **SQLite database** that your UI queries reactively.
:::note
While the majority of apps will probably use SQLite as the data store for persistence, LiveStore is flexible enough to materialize state into other targets as well (e.g. file systems).
:::
If you want to learn more, you can dive deeper into [how LiveStore works](/overview/how-livestore-works).
### Comparison with traditional state management like Redux
If you've used Redux, this pattern of "comitting events" will feel familiar: **Events are like actions, materializers are like reducers, and the SQLite state is like your store.**
But there are key differences:
| Redux | LiveStore |
| -------------------------------------------------- | ------------------------------------------- |
| Actions dispatch → reducers update in-memory state | Events commit → materializers update SQLite |
| State lost on refresh | Events persisted locally |
| Sync requires external setup | Sync built-in via eventlog |
| Fixed state shape | Query any shape with SQL |
## A practical example
Let's walk through a simple example of a todo list with LiveStore and React.
### Define your schema
At the core of every app built with LiveStore, you have a _schema_ which consists of three parts:
- **Events**: describe what can happen in your app
- **State**: defines how data is stored in your app
- **Materializers**: determines how events are mapped to state in your app
Here's an example:
## `reference/overview/introduction/schema.ts`
```ts filename="reference/overview/introduction/schema.ts"
// schema.ts
// 1. Define events (the things that can happen in your app)
export const events = {
todoCreated: Events.synced({
name: 'v1.TodoCreated',
schema: Schema.Struct({
id: Schema.String,
text: Schema.String,
}),
}),
todoCompleted: Events.synced({
name: 'v1.TodoCompleted',
schema: Schema.Struct({ id: Schema.String }),
}),
}
// 2. Define SQLite tables (how to query your state)
export const tables = {
todos: State.SQLite.table({
name: 'todos',
columns: {
id: State.SQLite.text({ primaryKey: true }),
text: State.SQLite.text({ default: '' }),
completed: State.SQLite.boolean({ default: false }),
},
}),
}
// 3. Define materializers (how to turn events into state)
const materializers = State.SQLite.materializers(events, {
'v1.TodoCreated': ({ id, text }) => tables.todos.insert({ id, text }),
'v1.TodoCompleted': ({ id }) => tables.todos.update({ completed: true }).where({ id }),
})
const state = State.SQLite.makeState({ tables, materializers })
export const schema = makeSchema({ events, state })
```
### Usage on the frontend
LiveStore comes with integrations for all major frontend frameworks, e.g. for [React](/framework-integrations/react-integration) or [Vue](/framework-integrations/vue-integration).
The [`queryDb`](/building-with-livestore/reactivity-system#reactive-sql-queries) function creates a [reactive query](/building-with-livestore/reactivity-system) which updates automatically when its data in the database changes. Here's how to use it in React:
## `reference/overview/introduction/todo-app.tsx`
```tsx filename="reference/overview/introduction/todo-app.tsx"
// TodoApp.tsx
const adapter = makeInMemoryAdapter()
const useAppStore = () =>
useStore({
storeId: 'my-app',
schema,
adapter,
batchUpdates,
})
// Define a reactive query
const visibleTodos$ = queryDb(() => tables.todos, {
label: 'visibleTodos',
})
type Todo = {
id: string
text: string
completed: boolean
}
export const TodoApp = () => {
const store = useAppStore()
// Reactively updates when todos change in the DB
const todos = store.useQuery(visibleTodos$)
const addTodo = useCallback(
(text: string) => {
// Commit an event to the store
store.commit(
events.todoCreated({
id: crypto.randomUUID(),
text,
}),
)
},
[store],
)
const completeTodo = useCallback(
(id: string) => {
// Commit an event to the store
store.commit(events.todoCompleted({ id }))
},
[store],
)
const handleAddTodo = useCallback(() => {
addTodo('New todo')
}, [addTodo])
return (
{todos.map((todo) => (
)
}
const TodoListItem = ({ todo, onComplete }: { todo: Todo; onComplete: (id: string) => void }) => {
const handleComplete = useCallback(() => {
onComplete(todo.id)
}, [onComplete, todo.id])
return (
)
}
```
This code replaces all the API calls, state management, UI update, caching, and synchronization logic you may be used to from writing apps in a more traditional way. If configured, it also automatically takes care of syncing data to other clients.
Also notice how there's no loading state for queries—SQLite runs in-memory on the main thread, so reads are synchronous and instant, making your app super snappy and reactive to user input.
## Why events?
But why use events at all, rather than directly mutating state?
### Benefits of using events for state management
- **Events capture intent, not just outcome.** When you mutate state directly (`todo.completed = true`), you lose the _why_. Events like `TodoCompleted` preserve the user's intent, which matters for debugging, analytics, undo/redo, and features like activity feeds.
- **Events decouple what happened from how it's stored.** Your state shape can evolve independently of your event history. Need a new denormalized table for performance? Just add a materializer—no data migration required.
- **Events make sync tractable.** Syncing mutable state across devices is hard (which field wins?). Syncing an append-only event log is simpler: you're merging histories, not reconciling conflicting states.
### Benefits of LiveStore's eventlog
The [eventlog](/building-with-livestore/events/#eventlog) sits the core of LiveStore and gives you several benefits:
- **Persistence**: Events survive page refreshes and app restarts
- **Sync**: Events replay identically across devices
- **History**: Full audit trail of every change (enables time travel and helps with debugging)
- **Flexibility**: Change your queries without migrations—just materialize differently
## How syncing works
LiveStore includes a **sync engine** which handles [syncing](/building-with-livestore/syncing) for you under the hood.
When you can enable syncing, the sync engine distributes your state across various other clients (these can be other browsers, apps, devices, servers—anything that can connect to your store via an [adapter](/overview/how-livestore-works#platform-adapters)).
LiveStore uses a push/pull model inspired by git:
1. Local events are committed immediately (optimistic updates by default)
1. Events sync to a central backend when online
1. Other clients pull new events and materialize them locally
1. Conflicts resolve deterministically (last-write-wins by default, or custom logic)
Here's an example that syncs your state via Cloudflare (using the [`@livestore/sync-cf`](/sync-providers/cloudflare/) package):
## `reference/overview/introduction/worker.ts`
```ts filename="reference/overview/introduction/worker.ts"
makeWorker({
schema,
sync: {
backend: makeWsSync({ url: `${location.origin}/sync` }),
},
})
```
That's all the configuration needed—your app works offline automatically. When connectivity returns, LiveStore syncs pending events and reconciles state.
## When LiveStore fits
LiveStore works well for:
- **Productivity apps** (todo lists, note-taking, project management, ...)
- **Collaborative tools** with multi-player support
- **Apps with complex local state** that need SQL-level queries
- **Local-first** apps with offline support
- **Cross-platform apps** (web, mobile, desktop, server)
- ... or any combination of the above
LiveStore may not fit if:
- Your data must live on an existing server database (consider [ElectricSQL](https://electric-sql.com) or [Zero](https://zero.rocicorp.dev))
- You're building a traditional client-server app without offline needs
- You need unbounded data that won't fit in client memory
If you're unsure, go through our [evaluation exercise](/overview/when-livestore) to find out whether LiveStore is a good fit for your project or [compare it with similar tools](/overview/technology-comparison).
## Next steps
- [Tutorial](/tutorial/0-welcome) — Step-by-step tutorial introducing the main concepts and workflows of LiveStore
- [Getting started with React](/getting-started/react-web) — Quickstart to set up a React app
- [How LiveStore works](/overview/how-livestore-works) — Deeper dive into the LiveStore architecture
- [Examples](/examples) — See LiveStore in action with TodoMVC, Linearlite, and more
# [Technology comparison](https://main--livestore-docs-dev.netlify.app/overview/technology-comparison/)
## TLDR of what sets LiveStore apart
- Uses combination of reactive, in-memory + synced, persisted SQLite for instant, synchronous queries
- Based on event-sourcing methodologies
- Client-centric (with great devtools)
## Other local-first/syncing technologies
To compare LiveStore with other local-first/syncing technologies, please see the [Local-First Landscape](https://www.localfirst.fm/landscape) resource.
## LiveStore vs Redux
LiveStore shares a lot of similarities with Redux in that sense that both are based on event-sourcing methodologies. Let's compare some of the core concepts:
- Redux actions are similar to LiveStore events: Both are used to describe "things that have happened"
- Redux views are similar to LiveStore's state (e.g. SQLite tables): Both are derived from the history of events/actions.
- A major difference here is that LiveStore's state materialized as a SQLite database allows for a lot more flexibility via dynamic queries and aggregations vs Redux's static views.
- Redux reducers are similar to LiveStore's materializers: Both are used to transform events/actions into a final state.
- Both Redux and LiveStore are client-centric.
- Both Redux and LiveStore provide powerful [devtools](/building-with-livestore/devtools).
While LiveStore can be used for the same use cases as Redux, LiveStore goes far beyond Redux in the following ways:
- LiveStore leverages SQLite for a more powerful state model allowing for flexible queries and aggregations with much simpler materialization logic.
- LiveStore supports client-persistence out of the box.
- LiveStore comes with a built-in [sync engine](/building-with-livestore/syncing) syncing events between clients.
As a downside compared to Redux, LiveStore has a slightly larger bundle size.
## Other state management libraries
- Zustand
- Redux Toolkit (RTK)
- MobX
- Jotai
- Xstate
- Recoil
- TanStack Query
# [When to use LiveStore (and when not)](https://main--livestore-docs-dev.netlify.app/overview/when-livestore/)
Choosing a data layer for a local-first app is a big decision and should be considered carefully. On a high level, LiveStore can be a good fit if ...
- you are looking for a principled data layer that works across platforms
- you want to use SQLite for your queries
- you like [event sourcing](/understanding-livestore/event-sourcing) to model data changes
- you are working on a new app as LiveStore doesn't yet provide a way to [re-use an existing database](/misc/faq#existing-database)
- the current [state of the project](/misc/state-of-the-project) aligns with your own timeline and requirements
## Evaluation exercise
A great way to evaluate whether LiveStore is a good fit for your application, is by trying to model your application events (and optionally state) schema. This exercise can be done in a few minutes and can give you a good indication of whether LiveStore is a good fit for your application.
### Example: Calendar/scheduling app
Let's say you are building a calendar/scheduling app, your events might include:
- `AppointmentScheduled`
- `AppointmentRescheduled`
- `AppointmentCancelled`
- `ParticipantInvitedToAppointment`
- `ParticipantRespondedToInvite`
From this you might want to derive the following state (modeled as SQLite tables):
- `Appointment`
- `id`
- `title`
- `description`
- `participants`
- `Participant`
- `id`
- `name`
- `email`
## Great use cases for LiveStore
- High-performance desktop/web/mobile apps
- e.g. productivity apps like
- AI agents
- Apps that need ...
- solid offline support
- audit logs
## Benefits of LiveStore
- Unified data layer combining local reactive state with globally synced data
- Easy to ...
- reason about
- debug
- test
- evolve
- operate
## Reasons when not to use LiveStore
- You have an existing database which is the source of truth of your data. (Better use [Zero](https://zero.rocicorp.dev) or [ElectricSQL](https://www.electricsql.com) for this.)
- Your app data is highly connected across users (like a social network / marketplace / etc.) or modeling your data via read-write model separation/event sourcing doesn't seem feasible.
- You want to build a more traditional client-server application with your primary data source being a remote server.
- You want a full-stack batteries-included solution (e.g. auth, storage, etc.). (Technologies like [Jazz](https://jazz.tools) or [Instant](https://instantdb.com) might be a better fit.)
- You don't like to model your data via read-write model separation/event sourcing or the trade-offs it involves.
- You're a new developer and are just getting started. LiveStore is a relatively advanced technology with many design trade-offs that might make most sense after you have already experienced some of the problems LiveStore is trying to solve.
- You want to keep your app bundle size as small as possible. LiveStore adds a few hundred kB to your app bundle size (mostly due to bundling SQLite).
## Considerations
### Database constraints
- All the client app data should fit into a in-memory SQLite database
- Depending on the target device having databases up to 1GB in size should be okay.
- If you you have more data, you can consider segmenting your database into multiple SQLite database (e.g. segmented per project, workspace, document, ...).
- You can either use the `storeId` option for the segmentation or there could also be a way to use the [SQLite attach feature](https://www.sqlite.org/lang_attach.html) to dynamically attach/detach databases.
### Syncing
LiveStore's syncing system is designed for small/medium-level concurrency scenarios (e.g. 10s / low 100s of users collaborating on the same thing for a given eventlog).
- Collaboration on multiple different eventlogs concurrently is supported and should be used to "scale horizontally".
### Other considerations
- How data flows / what's the source of truth?
# [Why LiveStore?](https://main--livestore-docs-dev.netlify.app/overview/why-livestore/)
## The problem LiveStore solves
Building modern apps with great UX means handling a lot of complexity:
- **State management**: Keeping UI in sync with data
- **Persistence**: Surviving refreshes and app restarts
- **Offline support**: Working without a network connection
- **Real-time sync**: Reflecting changes across devices instantly
- **Conflict resolution**: Handling concurrent edits gracefully
Traditionally, each of these concerns requires separate solutions—a state library, local storage, a sync service, optimistic update logic, retry queues. These pieces don't naturally fit together, leading to complex, fragile code and subtle bugs.
LiveStore provides a _unified architecture_ that handles all of these concerns through one coherent model: event sourcing.
As a positive side-effect, the simplicity of LiveStore's event-driven abstractions also leads to a superior DX compared to the traditional ways of dealing with state.
## What makes LiveStore different
### A real database, not just a cache
Most state management tools treat local data as a _cache_ of server state. This introduces complexity that's hard to manage due to the inherent intricacies of caching.
LiveStore flips this: your local SQLite database is the primary data source, and the server is just a sync target to which data is distributed automatically.
This means:
- **No loading states for reads**—queries execute synchronously against local SQLite
- **Full SQL power**—joins, aggregations, complex filters, all instant
- **Offline by default**—your app works the same whether online or not
### Events as the source of truth
Instead of syncing mutable state (which leads to "who wins?" conflicts), LiveStore syncs an append-only log of events. This is fundamentally easier to reason about:
- Events merge naturally—you're combining histories, not reconciling states
- Every change is auditable—you have a complete record of what happened
- State is always rebuildable—replay events to reconstruct any point in time
### Sync that actually works
LiveStore includes a battle-tested sync engine that handles the hard problems:
- **Optimistic updates**: Changes appear instantly, sync happens in the background
- **Automatic offline queue**: Events committed offline sync when connectivity returns
- **Deterministic conflict resolution**: Same events always produce the same state
- **Pluggable backends**: Use Cloudflare, ElectricSQL, or build your own
### Built for demanding apps
LiveStore was developed as the foundation for [Overtone](https://overtone.pro), a professional music application requiring 120fps performance with complex, real-time collaborative state. It's designed for apps where performance and reliability aren't negotiable.
### Open-source: By developers, for developers
LiveStore is entirely open-source. There is no company behind it and it's only possible through its generous [sponsors](/sustainable-open-source/sponsoring).
## LiveStore vs. the alternatives
### vs. State management libraries (Redux, Zustand, MobX)
These solve state management but not persistence or sync. You'll need to add:
- Local storage or IndexedDB for persistence
- A sync layer for real-time updates
- Optimistic update logic
- Offline queue management
LiveStore handles all of this out of the box.
### vs. Backend-as-a-Service (Firebase, Supabase)
These provide sync but treat the server as the source of truth. The consequences are:
- Reads require network round-trips (or complex caching)
- Offline support is limited or requires significant extra work
- You're locked into their data model and pricing
LiveStore is client-first, works fully offline, and syncs via any backend you choose.
### vs. Other local-first solutions (ElectricSQL, Zero, PowerSync)
These are excellent if you have an existing Postgres database you want to sync to clients. LiveStore is better when:
- You're building a new app without legacy data
- You want event sourcing semantics (not just row-level sync)
- You need the flexibility to materialize state in different ways
See the [local-first landscape](https://localfirst.fm/landscape) for a comprehensive comparison.
## A great developer experience (DX)
LiveStore is designed to make the right thing easy:
- **Type-safe schema**: Your events, tables, and queries are fully typed
- **Reactive by default**: UI updates automatically when data changes
- **Powerful devtools**: Inspect state, browse events, time-travel debug
- **Cross-platform**: Same mental model on web, mobile, desktop, and server
## When to choose LiveStore
**Choose LiveStore if:**
- You're building a new app that should work offline
- You want a unified solution for state, persistence, and sync
- Your app has complex local state that benefits from SQL queries
- You value auditability and the ability to replay/debug state changes
**Consider alternatives if:**
- You need to sync with an existing server database
- Your data won't fit in client memory
- You're building a traditional request/response app without offline needs
Still unsure? Try the [evaluation exercise](/overview/when-livestore#evaluation-exercise) to model your app's events and see if it feels natural.
# [AI](https://main--livestore-docs-dev.netlify.app/patterns/ai/)
- LiveStore is a great fit for building AI applications.
- Scenarios:
- Local RAG (via sqlite-vec (see [feature request](https://github.com/livestorejs/livestore/issues/127)) + local LLM e.g. Gemini Nano embedded in Chrome)
- Agentic applications
- Event <> tool calls
- Nice mapping
## Example
```ts
// TODO (contribution welcome)
```
# [Anonymous user transition](https://main--livestore-docs-dev.netlify.app/patterns/anonymous-user-transition/)
## Basic idea
- Locally choose a unique identifier for the user (e.g. via `crypto.randomUUID()`).
- You might want to handle the very unlikely case that the identifier is not unique (collision) on the sync backend.
- Persist this identifier locally (either via a separate LiveStore instance or via `localStorage`).
- Use this identifier in the `storeId` for the user-related LiveStore instance.
- Initially when the user is anonymous, the store won't be synced yet (i.e. no sync backend used in adapter).
- As part of the auth flow, the LiveStore instance is now synced with the same `storeId` to a sync backend which will sync all local events to the sync backend making sure the user keeps all their data.
# [App evolution](https://main--livestore-docs-dev.netlify.app/patterns/app-evolution/)
When building an app with LiveStore, you'll need to keep some things in mind when evolving your app.
## Schema changes
### State schema changes
Generally any kind of changes to your state schema (e.g. SQLite tables, ...) can be done at any time without any further considerations assuming the event materializer is updated to support the new schema.
### Event schema changes
Event schema changes require a bit more consideration. Changes to the event schema should generally be done in a backwards-compatible way. See [Event schema evolution](/building-with-livestore/events#schema-evolution) for more details.
## Parallel different app versions
In scenarios where you have multiple app versions rolled out in parallel (e.g. app version v3 with event schema v3 and app version v4 with event schema v4), you'll need to keep the following in mind:
App instances running version 4 might commit events that are not yet supported by version 3. Your app needs to decide how to handle this scenario in one of the following ways:
- Ignore unknown events
- Cause an error in the app for unknown events
- Handle events with a "catch all" event handler
- Let app render a "app update required" screen. App can still be used in read-only mode.
- ...
LiveStore exposes a dedicated `unknownEventHandling` configuration on `makeSchema` so you can codify the desired behaviour instead of sprinkling ad-hoc checks across your app. The default is `'warn'`, which logs every unknown event and keeps processing.
Set the strategy to `'ignore'` to silently skip forward-only events, `'fail'` to stop immediately (useful during development), or `'callback'` to forward them to custom telemetry while continuing to replay the log.
# [Auth](https://main--livestore-docs-dev.netlify.app/patterns/auth/)
LiveStore doesn't include built-in authentication or authorization support, but you can implement it in your app's logic.
## Pass an auth payload to the sync backend
Use the `syncPayload` store option to send a custom payload to your sync backend.
### Example
The following example sends the authenticated user's JWT to the server.
## `patterns/auth/store-with-auth.tsx`
```tsx filename="patterns/auth/store-with-auth.tsx"
const schema = {} as LiveStoreSchema
const storeId = 'demo-store'
const user = { jwt: 'user-token' }
const adapter = makeInMemoryAdapter()
const suspenseFallback = Loading...
// ---cut---
const useAppStore = () =>
useStore({
storeId,
schema,
adapter,
batchUpdates,
syncPayload: {
authToken: user.jwt, // Using a JWT
},
})
export const App = () => {
const [storeRegistry] = useState(() => new StoreRegistry())
return (
{/* Your app content */}
}
```
On the sync server, validate the token and allow or reject the sync based on the result. See the following example:
## `patterns/auth/pass-auth-payload.ts`
```ts filename="patterns/auth/pass-auth-payload.ts"
const JWT_SECRET = 'a-string-secret-at-least-256-bits-long'
export class SyncBackendDO extends makeDurableObject({
onPush: async (message) => {
console.log('onPush', message.batch)
},
onPull: async (message) => {
console.log('onPull', message)
},
}) {}
export default makeWorker({
syncBackendBinding: 'SYNC_BACKEND_DO',
validatePayload: async (payload: any, context) => {
const { storeId } = context
const { authToken } = payload
if (authToken == null) {
throw new Error('No auth token provided')
}
const user = await getUserFromToken(authToken)
if (user == null) {
throw new Error('Invalid auth token')
} else {
// User is authenticated!
console.log('Sync backend payload', JSON.stringify(user, null, 2))
}
// Check if token is expired
if (payload.exp !== undefined && payload.exp < Date.now() / 1000) {
throw new Error('Token expired')
}
await checkUserAccess(user, storeId)
},
enableCORS: true,
})
const getUserFromToken = async (token: string): PromiseLoading users...
)
.onSuccess((users) => (
-
{users.map((user) => (
- {user.name} ))}
Error: {error.message}
)
.render()
}
```
### Integrating Effect services
Combine Effect services with LiveStore operations using the store's runtime:
## `patterns/effect/store-setup/services.tsx`
```tsx filename="patterns/effect/store-setup/services.tsx"
// Example service definition
export class MyService extends Context.Tag('MyService')<
MyService,
{
processItem: (name: string) => Effect.Effect<{
name: string
metadata: Record