About spacetimedb-views
A skill for developers using SpacetimeDB to expose derived data through views. It covers view design, query choices, and reference material.
Key features
- 01Define public, read-only views
- 02Choose context based on the caller
- 03Filter and join with the query builder
- 04Limit reads and consult indexes
Use cases
- 01Expose filtered or joined data
- 02Share materialized results with subscribers
- 03Query data specific to a user
- 04Check indexes for frequently subscribed views
Install
Copy the command and run it in a terminal.
$
npx skills add https:/ / github.com/ danmossa/ spacetimedb-skills --skill spacetimedb-viewsAfter installing, type/spacetimedb-viewsin Claude Code to confirm it loaded.
Bundled filesreferences/functions-views.md
Details
From the project READMEUse this skill for derived data exposed through SpacetimeDB views.
Core view patterns
Views expose read-only, derived data to clients. Use them for filtered or joined results that should be computed server side instead of duplicating rows into another table.
TypeScript view shape:
export const high_scorers = spacetimedb.anonymousView(
{ name: "high_scorers", public: true },
t.array(players.rowType),
(ctx) =>
ctx.from.players
.where((p) => p.score.gte(1000n))
.where((p) => p.name.ne("BOT")),
);
Design rules
- Views must be public and have explicit names.
- Views are read-only. Use reducers for writes and tables for stored state.
- Use
anonymousView/AnonymousViewContextwhen every caller sees the same result; SpacetimeDB can share one materialized result across subscribers. - Use per-user
ViewContextonly when the result depends on the caller, such as "my inventory" or private messages. - Keep the read set small. Prefer indexed lookups or the module-side query builder for filters and joins.
- Do not default to
.iter()for views; load the reference for query-builder syntax,.iter()limitations, and primary-key inference details.
Reference map
| Need | Open |
|---|---|
| View definitions and examples | references/functions-views.md |
Guidance
- Use views when the user needs derived or filtered data rather than duplicated stored rows.
- Check the SQL reference for expression or query syntax details.
- Check table indexes before adding views that may become hot subscription paths.
Comments
Markdown supported