You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* feat(persistQueryClient): PersistQueryClientProvider
* feat(persistQueryClient): PersistQueryClientProvider
defer subscription if we are hydrating
* feat(persistQueryClient): PersistQueryClientProvider
make sure we do not subscribe if the component unmounts before restoring has finished
* feat(persistQueryClient): PersistQueryClientProvider
make unsubscribe a const so that we don't mutate what we've exposed
* feat(persistQueryClient): PersistQueryClientProvider
make hydrating queries go in fetchStatus: 'idle' instead of paused
because paused means we have started fetching and are pausing, and we will also continue, while with hydration, we haven't started fetching, and we also might not start if we get "fresh" data from hydration
* feat(persistQueryClient): PersistQueryClientProvider
don't export IsHydratingProvider, as it shouldn't be needed by consumers
* feat(persistQueryClient): PersistQueryClientProvider
provide onSuccess and onError callbacks to PersistQueryClientProvider so that you can react to the persisting having finished, to e.g. have a point where you can resumePausedMutations
* feat(persistQueryClient): PersistQueryClientProvider
tests for onSuccess callback, and remove onError callback, because the persister itself catches errors and removes the store
* feat(persistQueryClient): PersistQueryClientProvider
test for useQueries
* feat(persistQueryClient): PersistQueryClientProvider
docs
* make restore in mockPersister a bit slower to stabilize tests
* better persistQueryClient docs
* feat(PersistQueryClientProvider): make sure we can hydrate into multiple clients
and error handling
* offline example
* extract to custom hook
* remove onError callback
because errors are caught internally by persistQueryClient and the persisted client is then removed
* just ignore stale hydrations if the client changes
* Revert "just ignore stale hydrations if the client changes"
This reverts commit 91e2afb.
* just ignore stale hydrations if the client changes
this makes sure we only call onSuccess once, for the "latest" client
* since QueryClientProviderProps is now a union type, we can't extend it from an interface
Copy file name to clipboardExpand all lines: docs/src/pages/plugins/persistQueryClient.md
+62Lines changed: 62 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -159,6 +159,68 @@ There are actually three interfaces available:
159
159
-`PersistedQueryClientRestoreOptions` is used for `persistQueryClientRestore` (doesn't use `dehydrateOptions`).
160
160
-`PersistQueryClientOptions` is used for `persistQueryClient`
161
161
162
+
## Usage with React
163
+
164
+
[persistQueryClient](#persistQueryClient) will try to restore the cache and automatically subscribes to further changes, thus syncing your client to the provided storage.
165
+
166
+
However, restoring is asynchronous, because all persisters are async by nature, which means that if you render your App while you are restoring, you might get into race conditions if a query mounts and fetches at the same time.
167
+
168
+
Further, if you subscribe to changes outside of the React component lifecycle, you have no way of unsubscribing:
169
+
170
+
```js
171
+
// 🚨 never unsubscribes from syncing
172
+
persistQueryClient({
173
+
queryClient,
174
+
persister: localStoragePersister,
175
+
})
176
+
177
+
// 🚨 happens at the same time as restoring
178
+
ReactDOM.render(<App />, rootElement)
179
+
```
180
+
181
+
### PeristQueryClientProvider
182
+
183
+
For this use-case, you can use the `PersistQueryClientProvider`. It will make sure to subscribe / unsubscribe correctly according to the React component lifecycle, and it will also make sure that queries will not start fetching while we are still restoring. Queries will still render though, they will just be put into `fetchingState: 'idle'` until data has been restored. Then, they will refetch unless the restored data is _fresh_ enough, and _initialData_ will also be respected. It can be used _instead of_ the normal [QueryClientProvider](../reference/QueryClientProvider):
0 commit comments