Skip to content

persistQueryClient issues due to asynchronism #3245

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
TkDodo opened this issue Jan 29, 2022 · 0 comments · Fixed by #3248
Closed

persistQueryClient issues due to asynchronism #3245

TkDodo opened this issue Jan 29, 2022 · 0 comments · Fixed by #3248
Labels

Comments

@TkDodo
Copy link
Collaborator

TkDodo commented Jan 29, 2022

Describe the bug

when a page mounts that has queries, those queries go into a hard loading state even if we have data already restored from the persistQueryClient

Your minimal, reproducible example

https://codesandbox.io/s/tannerlinsley-react-query-forked-4fz2f

Steps to reproduce

  1. open the page - this should load and put data into the cache
  2. reload the page - data from localStorage is picked up

However - the query still goes into a hard loading state (check the console)
Additionally, initialData function is executed if you provide one
On our react 18 branch, if you provide Infinity staleTime, the query will also hang in loading state indefinitely. That is likely due to due to different batching / concurrent behaviour of react 18 and react-query hydrating the cache asynchronously while already fetching...

Expected behavior

when data is hydrated from an external storage, queries should:

  • not go into hard loading state
  • should not call initialData function
  • should only refetch if the data is considered stale

How often does this bug happen?

No response

Screenshots or Videos

No response

Platform

macos, chrome

react-query version

3.34.12, 4.0.0.-alpha9 and the react-18 branch

TypeScript version

No response

Additional context

The problem seems to be that persistQueryClient is asynchronous even for the webStoragePersister. That is necessary to provide a consistent api. However, it means that we kick off the read from the webstorage, and then the app may start to render. If the rendered page then has queries, they will go into loading state. The persister then calls hydrate, which will put data into the cache.

The behaviour of "who comes first" seems to be completely undefined. It could even be that the fetch finishes before the read from the persister.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant