Angular Query: How to handle persistence / restoration race condition #7570
Unanswered
OmerGronich
asked this question in
Q&A
Replies: 1 comment 1 reply
-
rendering the application after restore has completed seems fine to me. In React, we have a dedicated |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm trying to figure out how to use angular query with indexedDB persistence. I'm running into a race condition issue that I'm not sure exactly how to solve.
Just to explain my use case and what I'm trying to do exactly, I have requests that run with APP_INITIALIZER, requests for metadata or configuration data that only need to run once and be available across the app ASAP.
I'm trying to cache these requests using angular query so they don't delay the user if they try to open multiple tabs. Because these requests might return very large objects I'm using indexedDB as the persister.
issue repro

In my attempts to make this work I encountered an issue where the cache was being ignored, you can see this in action in the stackblitz above, if you open the chrome console you will see the logs where the query fn is called before the
persistQueryClientRestore
restores the data from indexedDB.After searching for similar discussions I encountered this comment by @TkDodo that explains why this scenario occurs:
ensureQueryData
does not have a built-in mechanism that tracks the restoring state.I did find a hacky solution, to bootstrap the application only after the restoring process is finished:
possible solution repro
This does work, but feels very wrong.
Is there a better way to go about this?
Beta Was this translation helpful? Give feedback.
All reactions