useQueries doesn't work with 'keepPreviousData' properly

[TIS-OMiddle]

Describe the bug

  const [count, setCount] = useState(0);
  const result = useQueries(
    [1, 2].map((item) => {
      return {
        queryKey: [item, count],
        queryFn: queryFn,
        keepPreviousData: true
      };
    })
  );

The result[x].data should be "previousData" when queryKey change, but it is undefined.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://codesandbox.io/s/usequeries-with-keeppreviousdata-c9cim?file=/src/index.js:559-781
2. Click '++count'
3. See result[x].data

Expected behavior
result[x].data should always be {} when query key changed

Screenshots

Desktop (please complete the following information):

• OS: Mac
• Browser: chrome
• Version: v90

[actaruss]

"useInfiniteQuery" seems to work better

[kreegr]

Ran into the same issue. The staleTime config is set to 0 by default. Haven't had the time yet to look through this code, but changing it to Infinity (for example) resolved the issue for me.

[TkDodo]

so I did take a bit of a look. It seems that we are trying to "match" observers by queryKey:

https://github.com/tannerlinsley/react-query/blob/8a613165fc7dbc5213f61ad75f29ba54d248a0df/src/core/queriesObserver.ts#L77-L80

which doesn't work if the key changes, so we create a new observer. A new observer doesn't know anything about the previous result it could possibly "keep", so you'll get a hard loading instead. Tricky situation.

• we could document that keepPreviousData doesn't work for useQueries and remove the options in TypeScript types as well.
• we could also try and match by index if we don't find an observer and want to keep previous data. This would probably fix your example, because your length is always the same. But if if's dynamic, we might still not find it and get a new observer instead....

[TkDodo]

So I took a stab and made a PR. Your codesandbox example works with the fix, have a look here: https://codesandbox.io/s/usequeries-with-keeppreviousdata-v92oh

[owlas]

Could this also cause a problem with useQuery if an observer is mounted after a key changes?

I have a problem where I'm using keepPreviousData: true, enabled: false with useQuery.

[TkDodo]

Could this also cause a problem with useQuery if an observer is mounted after a key changes?

I have a problem where I'm using keepPreviousData: true, enabled: false with useQuery.

if there is something not working, it's likely a separate issue. keepPreviousData for useQueries was just not implemented. If you have something, please open a separate issue with a codesandbox reproduction

[kaiofelipejs]

Hi @TkDodo!
I have the same scenario from @TIS-OMiddle and your fix works perfectly for my project (congrats!).
How we can help to this PR be merged?

[TkDodo]

I’m on vacation now an will take another look at everything once I’m back.
Maybe you can try out keepPreviousData with alternating lengths of useQueries (e.g. 2 vs 3 elements) on the PR. I don’t think it would work and there is an alternate suggestion on the PR for that case. Not sure what the desired outcome should be here so input would be appreciated.

[kaiofelipejs]

Based on your test, I created a new test with 3 elements on useQueries and works fine. I admit that I don't know all things about the project, but I believe that is correct. Do you want that I commit directly to your PR?

[TkDodo]

Do you want that I commit directly to your PR?

sure, if that works permission-wise 😅. Otherwise, feel free to add as a comment / suggestion and I'll add it.

[tannerlinsley]

🎉 This issue has been resolved in version 3.19.4 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀