updateQueries not working

apollo
1

I have written a query

query vehicles{
vehicles {
_id,
vehicleNumber,
vehicleType {
name
}
}
}

than a mutation

mutation addVehicle($vehicle: AddVehicleInput){
addVehicle(vehicle: $vehicle) {
_id,
vehicleNumber,
vehicleType {
name
}
}
}

Then in my component

mutate({
variables: {
vehicle,
},
updateQueries: {
vehicles: (previousQueryResult, { mutationResult }) => {
console.log(mutationResult);
console.log(previousQueryResult);
return { …previousQueryResult, mutationResult };
},
},
}).then(() => push(’/vehicles’));

But my update queries are never called. I have been looking around this for a long time but nothing works. Any idea would help me solve this issue. I can use refetchQueries but that is too expensive.

Thanks

2

Is it me or does refetchQueries literally never work?

3

I must agree… Any alternative? I’m returning aggregated results caused by the mutation, so update does not make sense. It needs to be recalculated server side, thus refetch. Yet, no luck with refetchQueries…

4

Okay… here’s my checklist for when I have trouble with refetchQueries… imagine we have a mutation that adds a user to the database.

  1. Am I sure that my server-side resolver is returning the full object(s) after the mutation runs (ie it returns the updated user record)
  2. Does my client-side mutation definition/declaration ask for the full object as the response (ie the user object)
  3. What variables do I have defined for this query I want to rerun (both client and server-side)? Are they uniform? What is the structure?
  4. Be 100% sure I pass in a variables object for each of the refetch queries objects… even if the query didn’t pass any variabels…so

[{ query: MY_QUERY, variables: { } }]

  1. if your query that you want rerun used variables-- try to use those same exact variables. If it had an _id variable, pass that in with your this.props.mutation({ variables, refetchQueries }) setup.
  2. Finally, sometimes you can examine the apollo store to see how it is naming the query… and it can help you see where you refetchQueries setup isn’t matching with apollos idea of your query.
  3. Not only do you want to use the same variables, you want to use them in the same order (as apollo I think stringifies your refetchQueries settings and tries to match them against a stringified version of the original query).

Bottom line, from what I’ve ran into, it’s usually apollo has your query looking different than the way you setup your refetchQueries settings… so it’s a matter of trying to figure out how apollo stringified the property name on the apollo store object and fixing your refetchQueries so apollo can reconcile the two.

1 Like
5

Could you do something manually in local state or redux or context with this.props.data.refetch().then(results => this.setState({ results })).catch();?

6

Thanks for the details. as far as i can tell I’m doing 1-8… Even under the apollo store if I rerun the selected query from cache it gives the old result and rerun from network I get the new result.

Tried playing with fetching policies but that did not work either.

What I now ended up doing is adding a key field to the variables of the gql query which does not do anything other than increase every time I need the query to rerun. Sort of a brutal force approach, but in this case I must make sure that new data is passed, and I could not get the more elegant refetchQueries to work…

7

hmm… so you tried network-only fetchPolicy too?

Are you using .graphql files or .js files for your graphql stuff? I’ve seen some weird caching issues with .graphql files in meteor.

8

Just js files.

Yes the ‘no-cache’ policy returned no data from the query, or no data arrive in the query name props in child component, and if I have tried ‘network-only’ but it spins my react into some loading loop… So did not investigate any further.

My react is quite complicated with this, its a query component inside a uniforms generated form which returns aggregated results as options for the user. If the user saves the form it needs to recalculate the aggregated options.