Query key unstable - API suggest value

[Lilja-at-funnel]

Struggling to come up with a good title. Also, this might be discussed elsewhere. Could not find anything on github.

Imagine if you had a service that would give you file configuration guesses on CSV files you sent to it. You don't know the delimiter, so you need the service to guess the delimiter used(, or ; in this case)

type Delimiter = "," | ";"
const guessDelimiter = async (delimiter: undefined | Delimiter) => {
  if (delimiter) {
    return delimiter;
  }
  // "Detect" the delimiter. In real world scenarios these are implemented properly. For now, just randomise it from the known ones.
  const arr = [",", ";"]
  return arr[Math.floor(Math.random() * arr.length)];
}

React code on the client.

const useGuess = (num: undefined | Delimiter ) => {
  return useQuery({
    queryKey: [num],
    queryFn: async () => {
      await new Promise((resolve) => setTimeout(resolve, 100));
      console.log("Guessing", num);
      return await guessDelimiter(num);
    }
  })
}
const [guess, setGuess] = React.useState(undefined);
const guessQuery = useGuess(guess);

React.useEffect(() => {
  if (guessQuery.data) {
    console.log(guessQuery.data, "was guessed")
    setGuess(guessQuery.data)
  }
})

Because we use react's useState, the query key for the delimiter will change and subsequently fire a request to the API. In this case, the request is unnecessary, as it's the exact same request.
It happens because the query key becomes unstable, but the request is immutable. So there needs to be some kind of way on the success callback to set that the delimiter in the query cache..

How would you solve this kind of quirk?

[TkDodo]

why does a query have a delimiter as part of the key when its job is to determine that delimiter? Also, why do you need to “copy” the data into local state? I think it should just be:

const useGuess = () => {
  return useQuery({
    queryKey: ['delimiter'],
    queryFn: guessDelimiter,
  })
}

const  { data } = useGuess()

[Lilja-at-funnel]

Hey Dominik. Thanks for the response!

In this case, the "real" use-case is that we are providing suggestions of the columns of the csv and we don't know the delimiter of the csv(among other things). We are sending which s3 object to read, with optional configuration:

{
    queryKey: [
      'guess',
      {
        fileId,
        headerRowIndex,
        dataStartRowIndex,
        sheetName,
        delimiter,
        fileMetadata,
      },
    ],
}

Most of the props after fileId are undefined, since it's difficult to know of these in before hand.

The API returns a decent guess of these properties. Which we then set to our redux store. Which in turn will trigger a new query fetch, since the query key has changed. By design, of course.

The useState in the example above is supposed to mimic an external state system. I agree that it fails to show its benefit with a minimal reproducible 😁

[TkDodo]

if everything after fileId is undefined and you don’t want a change to it to trigger another request - why do you need it in the queryKey ?