Releases: TanStack/query
Releases · TanStack/query
v2.0.0-next.5
2.0.0-next.5 (2020-06-19)
Bug Fixes
v1.5.9
v2.0.0-next.4
v2.0.0-next.3
2.0.0-next.3 (2020-06-18)
Bug Fixes
v2.0.0-next.2
v2.0.0-next.1
New Features
- The booleans
isSuccess,isErrorisLoadingand a new one calledisIdlehave been added to the queryInfo object returned byuseQueryand friends. These are derived safely from thequeryInfo.statusand are guaranteed to not overlap. In most situations, they are easier to use, less typo-prone than status strings and also more terse for determining what to render based on the status of a query. queryCachesis now exported, which allows you to clean up all query caches that were created. We do this in our own tests when multiple caches are used for testing and to be thorough.fetchMorenow supports an optionalpreviousoption, which will determine if the data you are fetching is should be prepended instead of appended to your infinite list. eg,fetchMore(nextPageVars, { previous: true })makeQueryCachenow accepts an optional configuration object. ThedefaultConfigobject is used to override the default query configuration config to use inside of this cache. Thefrozenoption if set totruewill simulate React Query being run on the server, where no queries are cached for privacy and safety concerns. This is the default when using React Query on the server and is optional. You can also set it totrueon the server and have it work as it would on the client. More information on this coming soon!refetchIntervalcan now be changed on the fly. Check out the auto-refetching example to see it in action!
Breaking Changes
- Conditional, falsy or nullish query keys have been replaced by the
enabledconfig flag. This flag must be a boolean-esque value, not a function. If you are looking to replace the throwable function option, you should instead use optional chaining, eg.useQuery(user?.id, fn, { enabled: user?.id }). - Dependent Queries (via the
enabledoption) will now start in a newidlestate if they are initialized with no data andenabled: false. refetchQuerieshas been replace byinvalidateQueries. Previously,refetchQuerieswould refetch any query key it matched that was stale, even if it was not currently being used on the screen. This has changed and it will now only refetch active queries (those being subscribed to with useQuery and friends). All other queries that it matches will simply be marked as "stale" and be refetched when they are rendered next, if ever. You can also pass aninvalidateQueries(queryKey, { refetchActive: false })option if you do not want active queries to refetch either. This should save some bandwidth for queries that were cached, but not in use that will no longer be fetched again until they are needed.- Config is now split into 3 parts,
shared,queriesandmutations
const globalConfig = {
shared: {
suspense,
queryKeySerializerFn,
},
queries: {
...shared,
enabled,
retry,
retryDelay,
staleTime,
cacheTime,
refetchOnWindowFocus,
refetchInterval,
queryFnParamsFilter,
refetchOnMount,
isDataEqual,
onError,
onSuccess,
onSettled,
throwOnError,
useErrorBoundary,
},
mutations: {
...shared,
throwOnError,
onMutate,
onError,
onSuccess,
onSettled,
useErrorBoundary,
},
}- All
forceoptions have been removed. Functions that are meant to update the query always will. If you need to check that a query is stale before calling one of these functions, you can usequeryCache.get(queryKey).state.isStaleto do so. - Optional
queryVariableshave been removed. These didn't make much sense to begin with, and if you still need them, you can just inline them in your query function anyway, eg.useQuery(['hello', 'world'], (a, b) => queryFn(a, b, customVariable1, customVariable2)) - As a migration tool, falsy and functional query keys will throw an error now, showing you where you need to convert to use the
enabledconfig option globalConfig.refetchAllOnWindowFocus, which previous overlapped in fuctionality with the query-levelrefetchOnWindowFocushas been consolidated to a singlerefetchOnWindowFocusthat can set in the the globalconfig.queries.refetchOnWindowFocusand also on a per query basis.- The
refetchfunction returned by useQuery and friends will now always trigger a refetch for the query, regardless if the query is stale or not. This is way more clear and reliable to deal with. prefetchQuerywill no longer disable the next render of that query using useQuery (and friends). Instead, thestaleTimewill be respected for the prefetchQuery call, so ifprefetchQuery(key, fn, { staletime: 5000 })is called, and thenuseQuery(key, fn, { staleTime: 1000 })is rendered within those initial 5000 milliseconds, the query will not refetch in the background. But if the stale time has been reached by the time useQuery renders, it will refetch in the background.prefetchQuery'sforceoption has been removed. When you callprefetchQuery, the queryFn will always be called, regardless if the query is stale or not.prefetchQuery'sthrowOnErroroption is now located in a fourth argument, after the query config, eg.prefetchQuery(key, fn, config, { throwOnError: true })