deep-jade

Updating mutation data from another mutation

Hi 🙂 I work on an app that heavily relies on outputs from LLMs, and as such we prefer using useMutation to fetch text generations which are not stored in a database. The main reason we can't use useQuery is that we can't allow requests to fire unintentionally. We tried using it, but had to turn off refetch and retry, set cacheTime and staleTime to 0 and set enable: false but there could still be a chance that a dependency is updated and another request is triggered which is bad for us. All the requests are triggered by user interactions. My problem is that different mutations might rely on the data from each other, so we keep a state variable and update it in the onSuccess callback of the mutations. I was wondering if we can somehow update the mutation result directly and not have to store it ourselves. Maybe we are approaching this all wrong, and if so I'd love to hear how we can do better! Thank you!

9 Replies

graceful-blue•3y ago

so useMutation is not really a state manager. It's really just a wrapper around your update function that handles the lifecycle for you. In v5, we'll have useMutationState where you can subscribe to updates from other mutations, but it still sounds like useQuery would be the better fit. if you set staleTime and cacheTime to Infinity, you basically opt-out of refetches.

deep-jadeOP•3y ago

Thanks for the reply! I'll take a look into useMutationState, that may help us with that Regarding staleTime and cacheTime set to Infinity, we are still exposed to the indirection between a click of a button and the query fetching, which might still result in more requests than we can allow (for example when a dep changes, without another button click).

graceful-blue•3y ago

the idea is to only change the dependencies when you want the query to run, e.g. after the user interaction. why would dependencies change before that?

deep-jadeOP•3y ago

I'll try to give a more concrete example. We're working on an AI-powered text editor, and we have a feature that let's users generate text through an AI language model. So to get those generations we can use useQuery like so:

function useAIGenerations(text, position) {
  return useQuery({
    queryKey: [text, position] // auto-filled with tanstack-query eslint rules
    queryFn() {
      return fetch("https://ai/generate", {body: {text, position}});
    }
  });
}

function useAIGenerations(text, position) {
  return useQuery({
    queryKey: [text, position] // auto-filled with tanstack-query eslint rules
    queryFn() {
      return fetch("https://ai/generate", {body: {text, position}});
    }
  });
}

We generate a few results and update the text to let the user pick which they prefer. So if my initial text was: "I like the beach.", my generations could be: ["It is magical", "I love the sand"] and the user picks the one they prefer. So we take the first one and add it to the text so now my text is "I like the beach. Is it magical", which would re-trigger the query. The only fix I found was to just set enabled to false, but that it probably not ideal

graceful-blue•3y ago

so if the user picks one suggestion, the text changes, but then you don't want another query? Isn't accepting the text as if the user had typed something in? But anyways, the more I think about it: https://ai/generate is not idempotent, because it will generate new stuff on the fly. So a query seems wrong. useMutationState could help, but I think making the request, taking the suggestion and adding it to useState is fine. You also don't really want caching on that endpoint, because it will create something new everytime it's called

deep-jadeOP•3y ago

Yeah the idempotency is the real issue here, I should have been clearer about that. OK then we'll stick with good ol' useState, thanks a lot!

absent-sapphire•2y ago

is not really a state manager

why does it expose the data property in that case? if it won't be a "state manager", it will simply return all the data in a callback/promise, right? currently, both queries and mutations expose data property, but only in the case of query, it's possible to set it manually.

graceful-blue•2y ago

okay it's a "local state manager" ,but not a global one like query

absent-sapphire•2y ago

if it's not global - why can we access any mutation via MutationCache / useMutationState ? 😉 the only difference I can see is API. there is no reason to prevent us from setting the data manually, if we need it. it makes much harder to build libraries over react query

Gaming

Programming

Updating mutation data from another mutation

Did you find this page helpful?