Avoid consecutive mutation requests

[goerwin]

It would be great to have an option to prevent multiple multations from being triggered. So that if a user fires a mutation multiple times, none of those does not go through if there is already one in progress.

I can use isLoading for it but sometimes I have a mutation that can be triggered for multiple places and checking the loading status everywhere is not ideal.

Something like this, maybe?

const { mutate, isLoading } = useMutation(getTodos, { disableMultipleMutations: true });
<button onClick={mutate}>Mutate</button> // Can click it multiple times and it will only fire one at a time

[TkDodo]

I think preventing the call of a function (in this case: mutate) is a check that should run in user-land.

there is also a global useIsMutating hook that will show you how many mutations are currently running, and it also supports lots of filtering options, e.g. per query key, in case you don't have access to isLoading of the mutation in question.

[BennyHinrichs]

An example solution is that if you have a button with something like <Button onClick={onSubmit}>Submit</Button> then you can add something like this.

const isMutating = Boolean(useIsMutating(['mutationKey']));
// use whatever library you want for your throttle
const throttledSubmit = useThrottle(onSubmit, 1000);
<Button onClick={throttledSubmit} disabled={isMutating}>Submit</Button>

For me, I was using Formik and the isMutating wasn't updating fast enough to block a double click. Adding the 1s throttle onto onSubmit successfully prevented double submits.

[vjau]

Knowing that you sometimes have to use a hack like useThrottle tells me that there should be a way to prevent double submit in the framework, don't you think ?

[vjau]

no, the public api. How would this "option" look like in your point of view?

I think it would be perhaps more logical to make it an enabled option, with a default value of true, to be isomorphic to useQuery.
Something like {concurrentEnabled:boolean}
The ban would be per-mutation, and not dependent on the value of the parameters passed.
When concurrentEnabled would be set to false for a mutation, any subsequent call to the mutation while it has not settled would be ignored.
I understand that this would not be the central way of preventing duplicates. It should probably be handled also at the server level and in react code by disabling the buttons, and/or doing optimistic updates in the first place.
But since a mutation is a side effect, i think it's not unreasonable wanting the communication layer to enforce it also if desired.
The race condition reported with formik sooner in the discussion make me come to this conclusion.

[ftzi]

It would have a great synergy with a debounce. The dev could just call the mutate function multiple times without worrying about race conditions/simultaneous requests. I suggest adding a debounceMs property to only get the latest call that doesn't have another one for Xms and that concurrentEnabled.

Would be reaaaally good, a game changer.

[TkDodo]

The ban would be per-mutation, and not dependent on the value of the parameters passed.

This is not in line with our concept of mutations where every call to .mutate creates a separate MutationObserver. It's totally fine to call mutate in a loop with different parameters.
If anything, this would need to happen on a per-variable basis, and then it quickly becomes more complex.

It also doesn't seem like anything I would want to do in a user interface. Shouldn't there be some feedback for the user that a mutation is currently in-flight?

The dev could just call the mutate function multiple times without worrying about race conditions/simultaneous requests

This is literally as simple as wrapping mutate in debounce from lodash:

const { mutate } = useMutation(...)

const debouncedMutate = debounce(mutate, 250)

[ftzi]

Still, would be better to have this functionality integrated

[TkDodo]

It's a tradeoff. Every new feature increases api surface, learning curve and bundle size. We would also likely need to add a 3rd party dependency. Features that are not often requested and can be implemented in user-land in an easy manner will not be added.

[Manitej66]

for those who are looking for the answer:

I used the below way to achieve global mutation deduplication:

inside setDefaultOptions:

onMutate(variables) {
  // Variable to store the mutation key
  let mutationKey = "";

  //  Object containing the maximum number of allowed mutations for each query key.
  // If a query key is not present, it defaults to 1 (only one mutation at a time)
  const maxConcurrentMutations = {
    ["foo"]: 1,
  };

  // Get the mutation count for the current mutation
  const currentMutationCount = qc.isMutating({
    // Find all mutations that match the current mutation
    predicate(mutation) {
      mutationKey = JSON.stringify(mutation.options.mutationKey);
      // because the variables are objects, we need to use a deep comparison
      return isEqual(mutation.state.variables, variables);
    },
    // make a strict comparison
    exact: true,
    // only consider mutations that are currently in flight
    fetching: true,
  });

  // If the mutation count is greater than its allowed count, it means that there is already a mutation
  // in flight for the same input. In that case, we reject the mutation
  if (
    currentMutationCount > (maxConcurrentMutations[mutationKey] || 1)
  ) {
    return Promise.reject();
  }
},

[fransachmadhw]

for those who are looking for the answer:

I used the below way to achieve global mutation deduplication:

inside setDefaultOptions:

onMutate(variables) {
  // Variable to store the mutation key
  let mutationKey = "";

  //  Object containing the maximum number of allowed mutations for each query key.
  // If a query key is not present, it defaults to 1 (only one mutation at a time)
  const maxConcurrentMutations = {
    ["foo"]: 1,
  };

  // Get the mutation count for the current mutation
  const currentMutationCount = qc.isMutating({
    // Find all mutations that match the current mutation
    predicate(mutation) {
      mutationKey = JSON.stringify(mutation.options.mutationKey);
      // because the variables are objects, we need to use a deep comparison
      return isEqual(mutation.state.variables, variables);
    },
    // make a strict comparison
    exact: true,
    // only consider mutations that are currently in flight
    fetching: true,
  });

  // If the mutation count is greater than its allowed count, it means that there is already a mutation
  // in flight for the same input. In that case, we reject the mutation
  if (
    currentMutationCount > (maxConcurrentMutations[mutationKey] || 1)
  ) {
    return Promise.reject();
  }
},

It's still not working unfortunately

[nicktiberi]

I may be misunderstanding here, but doesn't this only compare against the mutation variables?

What if you had a mutation with mutationKey: ['post'], variables: { id: 123 }, and another with mutationKey: ['comment'], variables: { id: 123 }?

If I'm understanding correctly, this would treat these mutations as identical and reject the second mutation, which does not seem ideal IMO. I guess you could add the mutationKey in the variables but that also doesn't seem ideal.

An alternate solution would involve creating a custom hook to wrap useMutation() and prevent mutations if they are already pending: https://medium.com/@jdimitrop/react-query-avoiding-duplicate-mutation-requests-38c722e7a2e9

[salmanbabri]

The best approach I've found so far is to utilize mutation states. You can check for isPending & isSuccess before executing mutation. And reset mutation on success.

I tried utilizing debounce/throttle of lodash, but it was not 100% fool proof. Mutation states are more consistent & easier to reason with.

[ftzi]

Can you please provide an example?

[salmanbabri]

Something like:-

const saveMutation = useMutation(// mutate fn);

Then in on submit you can do:-

const onSubmit = () => {
	if(saveMutation.isPending) return;
	saveMutation.mutate();
} 

[ftzi]

But if the ongoing API call has text: 'abc' and the new onSubmit is text: 'abcd', you would lose this new call