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(useQuery): offline queries
remove defaultQueryObserverOptions because it is the same as defaultQueryOptions and we can just use that
* feat(useQuery): offline queries
setup dependent default values, to make it easier to work with them
* feat(useQuery): offline queries
basic changes to retryer:
- pause the query before fetching depending upon networkMode
- pause retries depending upon networkRetry
* feat(useQuery): offline queries
move networkRetry and networkMode defaults to the retryer creation, because we need the same for mutations
* feat(useQuery): offline queries
decouple focus and online manager: we're now informing caches of a focus when we're focussed, and about an online event if we come online; if the retryer continues, it can then decide to not fetch depending on our networkMode
* feat(useQuery): offline queries
expose isPaused on the queryResult and make sure isFetching is false when we are paused
* feat(useQuery): offline queries
knowing if we can fetch depends on if we are paused or not, as other conditions should apply
also, rename options (not sure if that will stick though)
* feat(useQuery): offline queries
adjust existing tests for isPaused being exposed
* feat(useQuery): offline queries
fix existing test by setting options to emulate the previous behaviour, otherwise, with `mockNavigatorOnline` being set to false right from the start, the mutation would never fire off
* feat(useQuery): offline queries
adapt onOnline, onFocus tests to new behavior: they are now decoupled, and onOnline is always called even when not focused and vice versa. The retryer should make sure to not continue fetching if necessary
* feat(useQuery): offline queries
first test for networkMode
* feat(useQuery): offline queries
isFetching and isPaused are now derived and stored together in a fetchingState enum (idle, fetching, paused)
* feat(useQuery): offline queries
better networkMode api: online, always, offlineFirst (basically always but with paused retries)
* feat(useQuery): offline queries
more tests for networkMode: online
* feat(useQuery): offline queries
more tests for networkMode: online
* feat(useQuery): offline queries
tests for networkMode: always
* feat(useQuery): offline queries
fix tests that were influencing each other by using proper jest mocks for online and visibility state
* add paused queries to the devtools.tsx
* feat(useQuery): offline queries
never stop pausing when continueFn is called. Initially, I only had this guard for when it's called from the outside, e.g. for onWindowFocus while still being offline, but we need this always because otherwise query cancellation can potentially continue a paused query
* feat(useQuery): offline queries
okay, pausing multiple times was a bad idea, continueFn() will be called eventually anyways
* feat(useQuery): offline queries
attempt at offline toggle button
* feat(useQuery): offline queries
different icons, padding, color
* feat(useQuery): offline queries
i messed up the icon order
* feat(useQuery): offline queries
guard against illegal state transitions: paused queries can unmount or get cancelled, in which case we shouldn't continue them, even if we dispatch the continue event
* feat(useQuery): offline queries
fix devtools tests, account for paused queries
* Revert "feat(useQuery): offline queries"
This reverts commit a647f64.
* feat(useQuery): offline queries
keep the do-not-start logic out of the run function, and thus out of promiseOrValue. if the promise has already been resolved in the meantime, e.g. because of a `cancel`, the run method will just do nothing, while the previous logic would've started to fetch
* feat(useQuery): offline queries
show inactive as higher priority than paused
* feat(useQuery): offline queries
make sure that optimistic results don't show an intermediate fetching state, but go opmistically to paused instead
* feat(useQuery): offline queries
real result needs to match optimistic result
* feat(useQuery): offline queries
stupid mistake
* feat(useQuery): offline queries
keep status color and status label in sync
* feat(useQuery): offline queries
make networkMode param mandatory for canFetch (and default to online internally) so that we can't screw that up again
* feat(useQuery): offline queries
make sure test "finishes" to avoid prints to the console if another test goes online again
* feat(useQuery): offline queries
move cancel function to the top, as it's no longer dependent on the promise since the `.cancel` function is gone; all we need is to abort the signal and reject the promise of the retryer
* feat(useQuery): offline queries
inline canContinue, because it's now only called if the query is in paused state anyways
* feat(useQuery): offline queries
avoid the impossible state by not calling config.onContinue for already resolved queries, as that would put them right into fetching state again, without actually fetching
* feat(useQuery): offline queries
let resolved querie continue, but don't put them in fetching state
* feat(useQuery): offline queries
fix merge conflict and invert condition because no-negated-condition
* feat(useQuery): offline queries
add test for abort signal consumed - different results expected for node < 15 where we don't have AbortController, thus can't consume the signal
* feat(useQuery): offline queries
online queries should not fetch if paused and we go online when cancelled and no refetchOnReconnect
* feat(useQuery): offline queries
gc test
* feat(useQuery): offline queries
offlineFirst test
* feat(useQuery): offline queries
mock useMediaQuery to get rid of unnecessary check in devtools - if window is defined, `matchMedia` is also defined
* feat(useQuery): offline queries
use a higher retryDelay to make test more stable, otherwise, it might start retrying before we "go offline"
* feat(useQuery): offline queries
improve devtools test: check if onClick props are being called
* feat(useQuery): offline queries
add devtools test for offline mock
* feat(useQuery): offline queries
offline mutations test
* feat(useQuery): offline queries
network mode docs (unfinished)
* feat(useQuery): offline queries
network mode docs
* feat(useQuery): offline queries
fix merge conflicts
Copy file name to clipboardExpand all lines: docs/src/pages/guides/migrating-to-react-query-4.md
+39-4
Original file line number
Diff line number
Diff line change
@@ -20,7 +20,7 @@ To streamline all apis, we've decided to make all keys Arrays only:
20
20
21
21
### Separate hydration exports have been removed
22
22
23
-
With version [3.22.0](https://github.com/tannerlinsley/react-query/releases/tag/v3.22.0), hydration utilities moved into the react-query core. With v3, you could still use the old exports from `react-query/hydration`, but these exports have been removed with v4.
23
+
With version [3.22.0](https://github.com/tannerlinsley/react-query/releases/tag/v3.22.0), hydration utilities moved into the React Query core. With v3, you could still use the old exports from `react-query/hydration`, but these exports have been removed with v4.
24
24
25
25
```diff
26
26
- import { dehydrate, hydrate, useHydrate, Hydrate } from 'react-query/hydration'
@@ -29,7 +29,7 @@ With version [3.22.0](https://github.com/tannerlinsley/react-query/releases/tag/
29
29
30
30
### `notifyOnChangeProps` property no longer accepts `"tracked"` as a value
31
31
32
-
The `notifyOnChangeProps` option no longer accepts a `"tracked"` value. Instead, `useQuery` defaults to tracking properties. All queries using `notifyOnChangeProps: "tracked"` should be updated by removing this option.
32
+
The `notifyOnChangeProps` option no longer accepts a `"tracked"` value. Instead, `useQuery` defaults to tracking properties. All queries using `notifyOnChangeProps: "tracked"` should be updated by removing this option.
33
33
34
34
If you would like to bypass this in any queries to emulate the v3 default behavior of re-rendering whenever a query changes, `notifyOnChangeProps` now accepts an `"all"` value to opt-out of the default smart tracking optimization.
35
35
@@ -140,7 +140,7 @@ The `MutationCacheNotifyEvent` uses the same types as the `QueryCacheNotifyEvent
140
140
141
141
### The `src/react` directory was renamed to `src/reactjs`
142
142
143
-
Previously, react-query had a directory named `react` which imported from the `react` module. This could cause problems with some Jest configurations, resulting in errors when running tests like:
143
+
Previously, React Query had a directory named `react` which imported from the `react` module. This could cause problems with some Jest configurations, resulting in errors when running tests like:
144
144
145
145
```
146
146
TypeError: Cannot read property 'createContext' of undefined
@@ -161,7 +161,7 @@ This was confusing to many and also created infinite loops if `setQueryData` was
161
161
162
162
Similar to `onError` and `onSettled`, the `onSuccess` callback is now tied to a request being made. No request -> no callback.
163
163
164
-
If you want to listen to changes of the `data` field, you can best do this with a `useEffect`, where `data` is part of the dependency Array. Since react-query ensures stable data through structural sharing, the effect will not execute with every background refetch, but only if something within data has changed:
164
+
If you want to listen to changes of the `data` field, you can best do this with a `useEffect`, where `data` is part of the dependency Array. Since React Query ensures stable data through structural sharing, the effect will not execute with every background refetch, but only if something within data has changed:
165
165
166
166
```
167
167
const { data } = useQuery({ queryKey, queryFn })
@@ -188,8 +188,43 @@ Since these plugins are no longer experimental, their import paths have also bee
188
188
189
189
The [old `cancel` method](../guides/query-cancellation#old-cancel-function) that allowed you to define a `cancel` function on promises, which was then used by the library to support query cancellation, has been removed. We recommend to use the [newer API](../guides/query-cancellation) (introduced with v3.30.0) for query cancellation that uses the [`AbortController` API](https://developer.mozilla.org/en-US/docs/Web/API/AbortController) internally and provides you with an [`AbortSignal` instance](https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal) for your query function to support query cancellation.
190
190
191
+
### Queries and mutations, per default, need network connection to run
192
+
193
+
Please read the [New Features announcement](#proper-offline-support) about online / offline support, and also the dedicated page about [Network mode](../guides/network-mode)
194
+
195
+
Even though React Query is an Async State Manager that can be used for anything that produces a Promise, it is most often used for data fetching in combination with data fetching libraries. That is why, per default, queries and mutations will be `paused` if there is no network connection. If you want to opt-in to the previous behavior, you can globally set `networkMode: offlineFirst` for both queries and mutations:
196
+
197
+
```js
198
+
newQueryClient({
199
+
defaultOptions: {
200
+
queries: {
201
+
networkMode:'offlineFirst'
202
+
},
203
+
mutations: {
204
+
networkmode:'offlineFirst'
205
+
}
206
+
}
207
+
})
208
+
209
+
```
210
+
191
211
## New Features 🚀
192
212
213
+
### Proper offline support
214
+
215
+
In v3, React Query has always fired off queries and mutations, but then taken the assumption that if you want to retry it, you need to be connected to the internet. This has led to several confusing situations:
216
+
217
+
- You are offline and mount a query - it goes to loading state, the request fails, and it stays in loading state until you go online again, even though it is not really fetching.
218
+
- Similarly, if you are offline and have retries turned off, your query will just fire and fail, and the query goes to error state.
219
+
- You are offline and want to fire off a query that doesn't necessarily need network connection (because you _can_ use React Query for something other than data fetching), but it fails for some other reason. That query will now be paused until you go online again.
220
+
- Window focus refetching didn't do anything at all if you were offline.
221
+
222
+
With v4, React Query introduces a new `networkMode` to tackle all these issues. Please read the dedicated page about the new [Network mode](../guides/network-mode) for more information.
223
+
193
224
### Mutation Cache Garbage Collection
194
225
195
226
Mutations can now also be garbage collected automatically, just like queries. The default `cacheTime` for mutations is also set to 5 minutes.
227
+
228
+
### Tracked Queries per default
229
+
230
+
React Query defaults to "tracking" query properties, which should give you a nice boost in render optimization. The feature has existed since [v3.6.0](https://github.com/tannerlinsley/react-query/releases/tag/v3.6.0) and has now become the default behavior with v4.
React Query provides three different network modes to distinguish how [Queries](./queries) and [Mutations](./mutations) should behave if you have no network connection. This mode can be set for each Query / Mutation individually, or globally via the query / mutation defaults.
7
+
8
+
Since React Query is most often used for data fetching in combination with data fetching libraries, the default network mode is [online](#network-mode-online).
9
+
10
+
## Network Mode: online
11
+
12
+
In this mode, Queries and Mutations will not fire unless you have network connection. This is the default mode. If a fetch is initiated for a query, it will always stay in the `state` (`loading`, `idle`, `error`, `success`) it is in if the fetch cannot be made because there is no network connection. However, a `fetchStatus` is exposed additionally. This can be either:
13
+
14
+
-`fetching`: The `queryFn` is really executing - a request is in-flight.
15
+
-`paused`: The query is not executing - it is `paused` until you have connection again
16
+
-`idle`: The query is not fetching and not paused
17
+
18
+
The flags `isFetching` and `isPaused` are derived from this state and exposed for convenience.
19
+
20
+
> Keep in mind that it might not be enough to check for `loading` state to show a loading spinner. Queries can be in `state: 'loading'`, but `fetchStatus: 'paused'` if they are mounting for the first time, and you have no network connection.
21
+
22
+
If a query runs because you are online, but you go offline while the fetch is still happening, React Query will also pause the retry mechanism. Paused queries will then continue to run once you re-gain network connection. This is independent of `refetchOnReconnect` (which also defaults to `true` in this mode), because it is not a `refetch`, but rather a `continue`. If the query has been [cancelled](./query-cancellation) in the meantime, it will not continue.
23
+
24
+
## Network Mode: always
25
+
26
+
In this mode, React Query will always fetch and ignore the online / offline state. This is likely the mode you want to choose if you use React Query in an environment where you don't need an active network connection for your Queries to work - e.g. if you just read from `AsyncStorage`, or if you just want to return `Promise.resolve(5)` from your `queryFn`.
27
+
28
+
- Queries will never be `paused` because you have no network connection.
29
+
- Retries will also not pause - your Query will go to `error` state if it fails.
30
+
-`refetchOnReconnect` defaults to `false` in this mode, because reconnecting to the network is not a good indicator anymore that stale queries should be refetched. You can still turn it on if you want.
31
+
32
+
## Network Mode: offlineFirst
33
+
34
+
This mode is the middle ground between the first two options, where React Query will run the `queryFn` once, but then pause retries. This is very handy if you have a serviceWorker that intercepts a request for caching like in an [offline-first PWA](https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Offline_Service_workers), or if you use HTTP caching via the [Cache-Control header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#the_cache-control_header).
35
+
36
+
In those situations, the first fetch might succeed because it comes from an offline storage / cache. However, if there is a cache miss, the network request will go out and fail, in which case this mode behaves like an `online` query - pausing retries.
37
+
38
+
## Devtools
39
+
40
+
The [React Query Devtools](../devtools) will show Queries in a `paused` state if they would be fetching, but there is no network connection. There is also a toggle button to _Mock offline behavior_. Please note that this button will _not_ actually mess with your network connection (you can do that in the browser devtools), but it will set the [OnlineManager](../reference/onlineManager) in an offline state.
0 commit comments