Local-only optimistic updates

[arcanis]

I'm trying to figure out an acceptable way to write Storybook stories. Ideally, I'd be looking for the following characteristics:

• Data are initially loaded from a set of static fixtures
• Each mutation has an optimistic approach attached
• When triggering a mutation, urql applies the optimistic update to the local cache
• But, and that's where it gets tricky, it doesn't actually send the mutation to the server

In a sense, the page state would reset after each reload, which would be perfect for a Storybook story, since engineers would be able to test basic user interactions without needing a database. To make it better, I wouldn't have to write mock mutations, because I'd be able to leverage the optimistic code (which, in a sense, already defines mock results).

I'm trying to find out the best way to implement this strategy, and after looking at the documentation I have a few questions:

• I thought I'd be able to use updateQuery to insert the initial data within the cache. Unfortunately, it seems that cacheExchange doesn't actually expose the cache instance straight from creation - it's only available in callbacks. Given that, what would be the right way to implement initial data? Should I go all the way to a custom fetch exchange?

• Per the documentation, optimistic updates seem to be designed to be temporary, cleared once the server returns the actual mutation results. In my model however, I'd prefer them to be persistent, since there wouldn't be any backend behind the cache. Is it possible?

It's possible I'm going the completely wrong way, since I found few hints about this kind of workflow. Still, optimistic update definitions seem a great way to define in-memory mutations for development scenarios, and I wonder if there's something here I could leverage 🤔

[JoviDeCroock]

Hey,

Thanks for the detailed issue, one thing that I noticed is that you were referring to "creating your own fetch", we have a solution for this in place already. It's called the execute-exchange you can replace your fetch-exchange with this and get responses from there.

We chose not to expose the cache outside of GraphQL operations for the reason that this can introduce usages that lead to indeterministic behavior.

[arcanis]

Thanks for the fast answer! It seems like this would solve the initial data part, and perhaps how to make mutations - however, from the look of it, in order to share the optimistic updates, I'd have to do something like this, is it correct (basically adding an abstraction layer that both optimistic update and the exchange could leverage)? It may work, I'll dig into it!

const schema = buildSchema(`
  type TodoList {
    id: ID!
    todos: String!
  }

  type Todo {
    text: String!
  }
 
  type Query {
    todoList(id: ID!): [Todo]!
  }
 
  type Mutation {
    addTodo(id: ID!, text: String!): TodoList!
  }
`);

let todoLists = new Map();

const updates = {
  addTodo: (todoList, args) => {
    todoList.todos.push({text: args.text});
    return todoList;
  },
};

const rootValue = {
  todoLists: (_, args) => {
    return todoLists.get(args.id);
  },
  addTodo: (_, args) => {
    return updates.addTodo(todoLists.get(args.id), args);
  }
}

const cache = cacheExchange({
  optimistic: {
    addTodo: (variables, cache, info) => {
      return updates.addTodo(cache.readQuery({
        query: `query($id: ID!) { todoList(id: $id) { todos } }`,
        variables,
      }), variables);
    },
  },
});

[JoviDeCroock]

Hey I saw you marked is an answer after missing your last question, did you manage to find an answer to it? Your example looks correct to me.

[arcanis]

Yep, it seems to work. I'm still investigating good practices (should I make many small mutations, or one mutation per model that can mutate many fields at once), but the exchange-execute works as it should. One caveat: the documentation mentions that the args are the second parameter from the rootValue callbacks, but according to my test they are the first one.

[JoviDeCroock]

Oh thanks for notifying I'll double check that soon, normally in updaters there's a rootValue and in optimistic there isn't.

Personally, I make mutations that affect a specific model: updateTodo (can add an author, update multiple fields, ...), createAuthor, ... These defined in the cache.updaters and executeExchange will match the ones you are calling in the real implementation