0

Similar to the question here I have found that when using optimisticResponse and update for a mutation, that the id set from the response of the server is wrong. Furthermore, the id actually gets set by running the optimistic function again.

In the mutation below the refetchQueries is comment out on purpose. I don't want to use that. I want to manage everything through the update only.

Also notice the optimisticResponse id has a "-" prepended to it to prove the optimistic function is run twice:

id: "-" _ uuid(),

Mutation

graphql(MutationCreateChild, {
    options: {
      // refetchQueries: [{QueryAllChildren, variables: {limit: 1000}}],
      update: (proxy, {data: {createChild}}) => {
        const query = QueryAllChildren;
        const data = proxy.readQuery({query});

        data.listChildren.items.push(createChild);
        proxy.writeQuery({query, data});

        console.log("id: ", createChild.id);
      }
    },
    props: props => ({
      createChild: child => {
        return props.mutate({
          variables: child,
          optimisticResponse: () => ({
            createChild: {
              ...child,
              id: "-" + uuid(),
              __typename: "Child"
            }
          })
        });
      }
    })
  })

The output from the console.log statement is:

id:  -6c5c2a28-8bc1-49fe-92e1-2abade0d06ca
id:  -9e0a1c9f-d9ca-4e72-88c2-064f7cc8684e

While the actual request in the chrome developer console looks like this:

{"data":{"createChild":{"id":"f5bd1c27-2a21-40c6-9da2-9ddc5f05fd40",__typename":"Child"}}}

Is this a bug or am I not accessing the id correctly in the update function?

Menklab
  • 50
  • 1
  • 6

2 Answers2

1

It's a known issue, which has now been fixed. I imagine it'll get released to the npm registry soon.

https://github.com/awslabs/aws-mobile-appsync-sdk-js/pull/43

https://github.com/awslabs/aws-mobile-appsync-sdk-js/commit/d26ea1ca1a8253df11dea8f11c1749e7bad8ef05

ffxsam
  • 26,428
  • 32
  • 94
  • 144
0

Using your setup, I believe it is normal for the update function to be called twice and you are correct that the real id from the server will only be there the second time. Apollo takes the object you return from optimisticResponse and passes it to the update function so your UI can immediately show changes without waiting for the server. When the server response comes back, the update function is called again with the same state (i.e. the state without the optimistic result) where you can reapply the change with the correct value from the server.

As for why the second id you list with the '-' is not the same as the id you see in the chrome dev console, I am not sure. Are you sure that it was actually that request that matched up with that call to console.log?

mparis
  • 3,623
  • 1
  • 17
  • 16
  • thanks for the explanation and yes, what you describe is exactly what I would expect to happen. The issues is that the second call to the update function doesn't actually include the response from the server, but rather, the same object that was created in the optimistic response. I can confirm this is that case because doing an "update mutation" instead of a "create mutation" works the same way. The reason the id is different in the "create mutation" is that the uuid() function is called a second time. – Menklab Feb 25 '18 at 03:42