Immediate result for optimistic mutations

[qpre]

Hello,

When applying an optimistic result on a mutation, the promise returned by the executeMutation callback does not trigger until the API responds :

func MyComponent() {
   const [message, set_message] = useState('');
   const [result, execute_mutation] = useMutation({ query: MY_MUTATION_QUERY });
   
   const send_message = useCallback(() => {
       execute_mutation({ variables: {message} })
           // this will only trigger after the API is reached, but we might like it to get executed as soon as possible for the UX
          .then(() => set_message(''));
   }, [message, execute_mutation])
   
   return (
   <>
      <input value={message} onChange={set_message} />
      <button onClick={send_message}></button>
   </>
   )
}

Wouldn't it be nice to be able to react to a mutation's optimistic answer ?
(There might already be a way to do it but I couldn't find it in the docs)

Regards,

[kitten]

I assume you're referring to Graphcache's optimistic mutation? those indeed complete synchronously so something's definitely off here.

In most cases, you're probably missing a field in your optimistic configuration that's present in your selection set. In that case you may see a warning in the console. But it's extremely important to provide it enough data to fulfil the mutation itself (and to not update other queries subsequently with missing / partial data that you want to also update optimistically)

[qpre]

Thanks for your answer and sorry I failed at following this discussion.

to be clearer, here's an example I'm working with, using offlineExchange with an optimistic mutation:

// offline exchange configuration
{
 updates: {
      Mutation: {
        insert_messages_one(result, _args, cache, _info) {
          if (!_info.optimistic) {
            return;
          }

          return cache.updateQuery(
            {
              query: QUERY_MESSAGES,
              variables: { user_id },
            },
            (data) => {
              data?.messages?.unshift(result.insert_messages_one);
              return data;
            }
          );
        },
      },
    },
    optimistic: {
       insert_messages_one: (variables, cache, info) => {
          const { sender_id, content } = variables;

          return {
             __typename: 'messages',
             id: new Date().getTime(),
             read: false,
             created_at: new Date().toISOString(),
             sender_id,
          };
      },
    },
}

and later in the code

await client
   .mutation(MUT_ADD_MESSAGE, {
         sender_id,
         content
   })
   .toPromise();
   
   debugger;

   // refetch cached query for messages list

the previous debugger will only be reached when I'm online,
when offline, how can I be sure that the cache has been updated before I can clear the text field and refetch QUERY_MESSAGES ?

[kitten]

The call is synchronous but the mutations are basically in a fire-and-forget state once you're using an optimistic update. That means it may never complete (which incidentally means it'll keep your optimistic update around) but it'll also mean that you can observe the mutation completing and that promise resolving

[alexkirsz]

I'm facing what I believe to be the same issue. Here's an example akin to my setup:

type Post {
  id: ID!
  name: String!
}

input InputPost {
  id: ID!
  name: String!
}

type Mutation {
  updatePost($post: InputPost!): Post!
}

fragment FullPost on Post {
  id
  name
}

mutation UpdatePost($post: InputPost!) {
  updatePost(post: $InputPost) {
    ...FullPost
  }
}

// Set as cacheExchange.optimistic.updatePost
function updatePostOptimistic(
  args: UpdatePostMutationVariables
): FullPostFragment {
  return {
    __typename: "Post",
    ...args.post,
  };
}

const [result, executeUpdatePost] =
    useMutation(UpdatePostDocument);

useEffect(async () => {
  const result = await executeUpdatePost({ variables: { post: { id: "random-uuid", name: "Hello" } } });
  // This will only hit once the server has returned a result, *after* the optimistic update has been applied.
}, []);

I can see the optimistic update being applied live, but executeUpdatePost only resolves once the update has been completely executed on the server. Is there a way to tell urql to only wait until the optimistic update has been applied?

I'm not seeing any warnings in the console.

[jongbelegen]

I have the same request, it would be very helpful if you can choose to not let the promise wait for the server to respond.
But instead, resolve immediately with the optimistic result.

[mako-taco]

if the results of optimistic mutations don't surface themselves anywhere, what is the point of them?

[kitten]

There are several reasons why this is the case, but essentially we thought through this and the best way to achieve optimistic mutations while catering to an average app’s need is to still resolve and block on the mutation that’s executed on the API.

First of all, the main principle here is that optimistic mutations are inherently treated as unreliable.

• They will contain “fake data” to an extent or entirely
  • This may mean fake IDs and states that the server hasn't achieved yet
• They may fail and revert
  • This means that an early resolution will prevent errors from being seen
• They're subject to network conditions
  • This means that when they can't be sent, the UI shouldn't respond (and the error will be resolved; unless the offlineExchange is used)

Furthermore, because optimistic functions can be defined in the Graphcache configuration later on, their data isn’t resolved because this may lead to their data being chained into queries. This should be clear, and hence, we prevent this from being the case as much as possible by interrupting this — meaning, this can only happen when a query is chained into another query (i.e. page to page)

But, from a UI bindings standpoint, resolving immediately is unexpected for optimistic updates because it prevents us from representing a state. For example, let's say we have a mutation that does something important that alters multiple pieces of data on the current page. If we resolved immediately, you'd lose the ability to actually indicate to the user that this action has been committed, i.e. sent to the API.
I've often made UIs where a submit button, or other form-like action, would be blocked after the user interacted with it, or displayed a loading indicator. This behaviour is lost if we just threw the server result away and resolved immediately.

Also, from a standpoint of the optimistic update, any locally resolved value is one that is mostly based on local data already. In other words, the API of Graphcache encourages you to only write optimistic updates for mutations that have all their inputs and outputs known at the call site. This means that you can always treat the mutation as a fire-and-forget if you must (and use client.readQuery in the very worst cases to supplement more data)