@livestore/livestore 0.0.39 → 0.0.41-dev.0

package/README.md

@@ -16,13 +16,12 @@ LiveStore provides a highly structured data model for your React components. It
 
 ## Reads
 
-To define the data used by a component, you use the `useQuery` hook. There are 3 parts to defining the data:
+To define the data used by a component, you use the `useQuery` hook. There are 2 parts to defining the data:
 
 - **local state**: This is the equivalent of `React.useState`, but in a relational style. Each component instance gets a row in a database table to store local state. You define the schema for the table that stores this component state. In your component, you can read/write local state.
 - **reactive queries**: Often it's not enough to just read/write local state, you also need to query data in the global database (eg, table of todos, or table of music tracks). To do this, you can define reactive SQL or GraphQL queries. The query strings can be _dynamic_ and depend on local state or other queries. You can also `.pipe` the results of any SQL or GraphQL query to do further downstream transformations.
-- **component key**: Every LiveStore component needs to have a _component key_ defined. This defines an identity for each instance of the component. Any component instances with the same key will share their local state / reactive queries.
 
-Let's see an example. This doesn't have any local state, just queries and a component key. (TODO: add an example with local state.)
+Let's see an example. This doesn't have any local state, just queries.
 
 We have a todos app which has a global table called `app`, which always has one row. It has a column called `filter` which has the value `active`, `completed`, or `all`. We want to use this value to query for only the todos which should be visible with that filter. Here's the code:
 
@@ -47,45 +46,37 @@ export const MyApp: React.FC = () => {
 
 ## Writes
 
-Writes happen through actions: structured mutations on the LiveStore datastore. Think closer to Redux-style actions at the domain level, rather than low-level SQL writes. This makes it clearer what's going on in the code, and enables other things like sync / undo in the future.
+Writes happen through mutations: structured mutations on the LiveStore datastore. Think closer to Redux-style mutations at the domain level, rather than low-level SQL writes. This makes it clearer what's going on in the code, and enables other things like sync / undo in the future.
 
-Write actions can be accessed via the `useLiveStoreActions` hook. This is global and not component-scoped. (If you want to do a write that references some local state, you can just pass it in to the action arguements.)
+Write mutations can be accessed via the `useLiveStoreActions` hook. This is global and not component-scoped. (If you want to do a write that references some local state, you can just pass it in to the mutation arguements.)
 
 ```ts
-const { completeTodo, uncompleteTodo, deleteTodo } = useLiveStoreActions()
+const { store } = useStore()
 
 // We record an event that specifies marking complete or incomplete,
 // The reason is that this better captures the user's intention
 // when the event gets synced across multiple devices--
 // If another user toggled concurrently, we shouldn't toggle it back
-const toggleTodo = (todo: Todo) => {
-  if (!todo.completed) {
-    completeTodo({ id: todo.id })
-  } else {
-    uncompleteTodo({ id: todo.id })
-  }
-}
+const toggleTodo = (todo: Todo) =>
+  store.mutate(todo.completed ? mutations.uncompleteTodo({ id: todo.id }) : mutations.completeTodo({ id: todo.id }))
 ```
 
 ## Defining dependencies
 
-LiveStore tracks which tables are read by each query and written by each action, in order to determine which queries need to be re-run in response to each write.
+LiveStore tracks which tables are read by each query and written by each mutation, in order to determine which queries need to be re-run in response to each write.
 
 In the future we want to do this more automatically via analysis of queries, but currently this write/read table tracking is done manually. It's very important to correctly annotate write and reads with table names, otherwise reactive updates won't work correctly.
 
 Here's how writes and reads are annotated.
 
-**Write actions**: annotate the SQL statement in the action definition, like this:
+**Write mutations**: annotate the SQL statement in the mutation definition, like this:
 
 ```ts
-newPlayerContext: {
-  statement: ({ contextId }) => {
-    return {
-      sql: sql`insert into player_context (id, timestamp) values ('${contextId}', ${Date.now()})`,
-      writeTables: ['player_context'],
-    }
-  },
-},
+export const completeTodo = defineMutation(
+  'completeTodo',
+  Schema.struct({ id: Schema.string }),
+  sql`UPDATE todos SET completed = true WHERE id = $id`,
+)
 ```
 
 **GraphQL:** annotate the query in the resolver, like this:
@@ -94,7 +85,7 @@ newPlayerContext: {
 spotifyAlbum = (albumId: string) => {
   this.queriedTables.add('album_images').add('albums')
 
-  const albums = this.db.select<AlbumSrc>(sql`
+  const albums = this.db.select<AlbumSrc[]>(sql`
       select id, name,
       (
         select image_url