)
+ : null}
)
}
-function App () {
+function App() {
return (
diff --git a/docs/react/adapters/solid-query.md b/docs/react/adapters/solid-query.md
index b42bd624f4..616d4512c5 100644
--- a/docs/react/adapters/solid-query.md
+++ b/docs/react/adapters/solid-query.md
@@ -1,21 +1,25 @@
---
-title: Solid Query
+title: Solid Query
---
-The `@tanstack/solid-query` package provides a 1st-class API for using TanStack Query with SolidJS.
+The `@tanstack/solid-query` package provides a 1st-class API for using TanStack Query with SolidJS.
## Example
```tsx
-import { QueryClient, QueryClientProvider, createQuery } from '@tanstack/solid-query'
+import {
+ QueryClient,
+ QueryClientProvider,
+ createQuery,
+} from '@tanstack/solid-query'
import { Switch, Match, For } from 'solid-js'
const queryClient = new QueryClient()
function Example() {
const query = createQuery({
- queryKey: () => ['todos'],
- queryFn: fetchTodos
+ queryKey: () => ['todos'],
+ queryFn: fetchTodos,
})
return (
@@ -28,9 +32,7 @@ function Example() {
Error: {query.error.message}
-
- {(todo) =>
{todo.title}
}
-
+ {(todo) =>
{todo.title}
}
@@ -44,7 +46,6 @@ function App() {
)
}
-
```
## Available Functions
@@ -61,26 +62,23 @@ Solid Query offers useful primitives and functions that will make managing serve
- `QueryClient`
- `QueryClientProvider`
-
-
-
## Important Differences between Solid Query & React Query
-Solid Query offers an API similar to React Query, but there are some key differences to be mindful of.
+Solid Query offers an API similar to React Query, but there are some key differences to be mindful of.
- To maintain their reactivity, Query keys need to be wrapped inside a function while using `createQuery`, `createQueries`, `createInfiniteQuery` and `useIsFetching`.
```tsx
// ❌ react version
useQuery({
- queryKey: ["todos", todo],
- queryFn: fetchTodos
+ queryKey: ['todos', todo],
+ queryFn: fetchTodos,
})
// ✅ solid version
createQuery({
- queryKey: () => ["todos", todo()],
- queryFn: fetchTodos
+ queryKey: () => ['todos', todo()],
+ queryFn: fetchTodos,
})
```
@@ -91,14 +89,14 @@ import { For, Suspense } from 'solid-js'
function Example() {
const query = createQuery({
- queryKey: () => ['todos'],
- queryFn: fetchTodos
+ queryKey: () => ['todos'],
+ queryFn: fetchTodos,
})
return (
{/* ✅ Will trigger loading fallback, data accessed in a suspense context. */}
-
+ {(todo) =>
{todo.title}
}
{/* ❌ Will not trigger loading fallback, data not accessed in a suspense context. */}
@@ -111,7 +109,11 @@ function Example() {
- Solid Query primitives (`createX`) do not support destructuring. The return value from these functions is a store, and their properties are only tracked in a reactive context.
```tsx
-import { QueryClient, QueryClientProvider, createQuery } from '@tanstack/solid-query'
+import {
+ QueryClient,
+ QueryClientProvider,
+ createQuery,
+} from '@tanstack/solid-query'
import { Match, Switch } from 'solid-js'
const queryClient = new QueryClient()
@@ -175,7 +177,7 @@ const queryClient = new QueryClient()
function Example() {
const [enabled, setEnabled] = createSignal(false)
- const query = createQuery({
+ const query = createQuery({
queryKey: () => ['todos'],
queryFn: fetchTodos,
// ❌ passing a signal directly is not reactive
@@ -197,9 +199,7 @@ function Example() {
@@ -110,9 +110,7 @@ To ensure a seamless querying process without conflicts, it's highly recommended
[//]: # 'Example1'
```jsx
- !isFetching && fetchNextPage()}
-/>
+ !isFetching && fetchNextPage()} />
```
[//]: # 'Example1'
@@ -197,8 +195,8 @@ queryClient.setQueryData(['projects'], (data) => ({
```tsx
queryClient.setQueryData(['projects'], (data) => ({
- pages: data.pages.slice(0,1),
- pageParams: data.pageParams.slice(0,1),
+ pages: data.pages.slice(0, 1),
+ pageParams: data.pageParams.slice(0, 1),
}))
```
@@ -206,7 +204,6 @@ queryClient.setQueryData(['projects'], (data) => ({
Make sure to always keep the same data structure of pages and pageParams!
-
[//]: # 'Example8'
## What if I want to limit the number of pages?
@@ -235,7 +232,7 @@ useInfiniteQuery({
## What if my API doesn't return a cursor?
-If your API doesn't return a cursor, you can use the `pageParam` as a cursor. Because `getNextPageParam` and `getPreviousPageParam` also get the `pageParam`of the current page, you can use it to calculate the next / previous page param.
+If your API doesn't return a cursor, you can use the `pageParam` as a cursor. Because `getNextPageParam` and `getPreviousPageParam` also get the `pageParam`of the current page, you can use it to calculate the next / previous page param.
[//]: # 'Example9'
@@ -246,13 +243,13 @@ return useInfiniteQuery({
initialPageParam: 0,
getNextPageParam: (lastPage, allPages, lastPageParam) => {
if (lastPage.length === 0) {
- return undefined
+ return undefined
}
return lastPageParam + 1
},
getPreviousPageParam: (firstPage, allPages, firstPageParam) => {
if (firstPageParam <= 1) {
- return undefined
+ return undefined
}
return firstPageParam - 1
},
diff --git a/docs/react/guides/migrating-to-react-query-3.md b/docs/react/guides/migrating-to-react-query-3.md
index e251f38c63..aed7f6aa06 100644
--- a/docs/react/guides/migrating-to-react-query-3.md
+++ b/docs/react/guides/migrating-to-react-query-3.md
@@ -137,7 +137,7 @@ useQuery(['post', id], () => fetchPost(id))
If you still insist on not using inline functions, you can use the newly passed `QueryFunctionContext`:
```tsx
-useQuery(['post', id], context => fetchPost(context.queryKey[1]))
+useQuery(['post', id], (context) => fetchPost(context.queryKey[1]))
```
### Infinite Query Page params are now passed via `QueryFunctionContext.pageParam`
@@ -183,18 +183,14 @@ The `useInfiniteQuery()` interface has changed to fully support bi-directional i
One direction:
```tsx
-const {
- data,
- fetchNextPage,
- hasNextPage,
- isFetchingNextPage,
-} = useInfiniteQuery(
- 'projects',
- ({ pageParam = 0 }) => fetchProjects(pageParam),
- {
- getNextPageParam: (lastPage, pages) => lastPage.nextCursor,
- }
-)
+const { data, fetchNextPage, hasNextPage, isFetchingNextPage } =
+ useInfiniteQuery(
+ 'projects',
+ ({ pageParam = 0 }) => fetchProjects(pageParam),
+ {
+ getNextPageParam: (lastPage, pages) => lastPage.nextCursor,
+ },
+ )
```
Both directions:
@@ -214,29 +210,25 @@ const {
{
getNextPageParam: (lastPage, pages) => lastPage.nextCursor,
getPreviousPageParam: (firstPage, pages) => firstPage.prevCursor,
- }
+ },
)
```
One direction reversed:
```tsx
-const {
- data,
- fetchNextPage,
- hasNextPage,
- isFetchingNextPage,
-} = useInfiniteQuery(
- 'projects',
- ({ pageParam = 0 }) => fetchProjects(pageParam),
- {
- select: data => ({
- pages: [...data.pages].reverse(),
- pageParams: [...data.pageParams].reverse(),
- }),
- getNextPageParam: (lastPage, pages) => lastPage.nextCursor,
- }
-)
+const { data, fetchNextPage, hasNextPage, isFetchingNextPage } =
+ useInfiniteQuery(
+ 'projects',
+ ({ pageParam = 0 }) => fetchProjects(pageParam),
+ {
+ select: (data) => ({
+ pages: [...data.pages].reverse(),
+ pageParams: [...data.pageParams].reverse(),
+ }),
+ getNextPageParam: (lastPage, pages) => lastPage.nextCursor,
+ },
+ )
```
### Infinite Query data now contains the array of pages and pageParams used to fetch those pages.
@@ -244,7 +236,7 @@ const {
This allows for easier manipulation of the data and the page params, like, for example, removing the first page of data along with it's params:
```tsx
-queryClient.setQueryData(['projects'], data => ({
+queryClient.setQueryData(['projects'], (data) => ({
pages: data.pages.slice(1),
pageParams: data.pageParams.slice(1),
}))
@@ -277,10 +269,10 @@ The `mutate` function can be used when using callbacks:
const { mutate } = useMutation({ mutationFn: addTodo })
mutate('todo', {
- onSuccess: data => {
+ onSuccess: (data) => {
console.log(data)
},
- onError: error => {
+ onError: (error) => {
console.error(error)
},
onSettled: () => {
@@ -393,7 +385,7 @@ import { setLogger } from 'react-query'
// Log with Sentry
setLogger({
- error: error => {
+ error: (error) => {
Sentry.captureException(error)
},
})
@@ -418,13 +410,14 @@ setConsole({
In version 3 **this is done automatically when React Query is used in React Native**.
-
### Typescript
+
#### `QueryStatus` has been changed from an [enum](https://www.typescriptlang.org/docs/handbook/enums.html#string-enums) to a [union type](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#union-types)
So, if you were checking the status property of a query or mutation against a QueryStatus enum property you will have to check it now against the string literal the enum previously held for each property.
Therefore you have to change the enum properties to their equivalent string literal, like this:
+
- `QueryStatus.Idle` -> `'idle'`
- `QueryStatus.Loading` -> `'loading'`
- `QueryStatus.Error` -> `'error'`
@@ -460,7 +453,7 @@ import { useQuery } from 'react-query'
function User() {
const { data } = useQuery(['user'], fetchUser, {
- select: user => user.username,
+ select: (user) => user.username,
})
return
Username: {data}
}
@@ -512,7 +505,7 @@ A `QueryObserver` can be used to create and/or watch a query:
```tsx
const observer = new QueryObserver(queryClient, { queryKey: 'posts' })
-const unsubscribe = observer.subscribe(result => {
+const unsubscribe = observer.subscribe((result) => {
console.log(result)
unsubscribe()
})
@@ -530,7 +523,7 @@ const observer = new InfiniteQueryObserver(queryClient, {
getPreviousPageParam: (firstPage, allPages) => firstPage.prevCursor,
})
-const unsubscribe = observer.subscribe(result => {
+const unsubscribe = observer.subscribe((result) => {
console.log(result)
unsubscribe()
})
@@ -546,7 +539,7 @@ const observer = new QueriesObserver(queryClient, [
{ queryKey: ['post', 2], queryFn: fetchPost },
])
-const unsubscribe = observer.subscribe(result => {
+const unsubscribe = observer.subscribe((result) => {
console.log(result)
unsubscribe()
})
diff --git a/docs/react/guides/migrating-to-react-query-4.md b/docs/react/guides/migrating-to-react-query-4.md
index 467ebd4712..38779170af 100644
--- a/docs/react/guides/migrating-to-react-query-4.md
+++ b/docs/react/guides/migrating-to-react-query-4.md
@@ -139,7 +139,9 @@ In order to make bailing out of updates possible by returning `undefined`, we ha
Further, it is an easy bug to produce `Promise` by adding logging in the queryFn:
```tsx
-useQuery(['key'], () => axios.get(url).then(result => console.log(result.data)))
+useQuery(['key'], () =>
+ axios.get(url).then((result) => console.log(result.data)),
+)
```
This is now disallowed on type level; at runtime, `undefined` will be transformed to a _failed Promise_, which means you will get an `error`, which will also be logged to the console in development mode.
@@ -420,8 +422,8 @@ React Query defaults to "tracking" query properties, which should give you a nic
When using the [functional updater form of setQueryData](../reference/QueryClient#queryclientsetquerydata), you can now bail out of the update by returning `undefined`. This is helpful if `undefined` is given to you as `previousValue`, which means that currently, no cached entry exists and you don't want to / cannot create one, like in the example of toggling a todo:
```tsx
-queryClient.setQueryData(['todo', id], previousTodo =>
- previousTodo ? { ...previousTodo, done: true } : undefined
+queryClient.setQueryData(['todo', id], (previousTodo) =>
+ previousTodo ? { ...previousTodo, done: true } : undefined,
)
```
diff --git a/docs/react/guides/mutations.md b/docs/react/guides/mutations.md
index 2f6526464e..16b5e64253 100644
--- a/docs/react/guides/mutations.md
+++ b/docs/react/guides/mutations.md
@@ -231,7 +231,8 @@ useMutation({
},
})
-[('Todo 1', 'Todo 2', 'Todo 3')].forEach((todo) => {
+const todos = ['Todo 1', 'Todo 2', 'Todo 3']
+todos.forEach((todo) => {
mutate(todo, {
onSuccess: (data, error, variables, context) => {
// Will execute only once, for the last mutation (Todo 3),
diff --git a/docs/react/guides/optimistic-updates.md b/docs/react/guides/optimistic-updates.md
index 45eb734236..f733d305b1 100644
--- a/docs/react/guides/optimistic-updates.md
+++ b/docs/react/guides/optimistic-updates.md
@@ -10,33 +10,33 @@ React Query provides two ways to optimistically update your UI before a mutation
This is the simpler variant, as it doesn't interact with the cache directly.
[//]: # 'ExampleUI1'
+
```tsx
- const { isPending, submittedAt, variables, mutate, isError } = useMutation({
- mutationFn: (newTodo: string) => axios.post('/api/data', { text: newTodo }),
- // make sure to _return_ the Promise from the query invalidation
- // so that the mutation stays in `pending` state until the refetch is finished
- onSettled: async () => {
- return await queryClient.invalidateQueries({ queryKey: ['todos'] })
- },
- })
+const { isPending, submittedAt, variables, mutate, isError } = useMutation({
+ mutationFn: (newTodo: string) => axios.post('/api/data', { text: newTodo }),
+ // make sure to _return_ the Promise from the query invalidation
+ // so that the mutation stays in `pending` state until the refetch is finished
+ onSettled: async () => {
+ return await queryClient.invalidateQueries({ queryKey: ['todos'] })
+ },
+})
```
+
[//]: # 'ExampleUI1'
you will then have access to `addTodoMutation.variables`, which contain the added todo. In your UI list, where the query is rendered, you can append another item to the list while the mutation is `pending`:
[//]: # 'ExampleUI2'
+
```tsx
{todoQuery.items.map((todo) => (
{todo.text}
))}
- {isPending && (
-
- {variables}
-
- )}
+ {isPending &&
{variables}
}
```
+
[//]: # 'ExampleUI2'
We're rendering a temporary item with a different `opacity` as long as the mutation is pending. Once it completes, the item will automatically no longer be rendered. Given that the refetch succeeded, we should see the item as a "normal item" in our list.
@@ -44,18 +44,18 @@ We're rendering a temporary item with a different `opacity` as long as the mutat
If the mutation errors, the item will also disappear. But we could continue to show it, if we want, by checking for the `isError` state of the mutation. `variables` are _not_ cleared when the mutation errors, so we can still access them, maybe even show a retry button:
[//]: # 'ExampleUI3'
+
```tsx
-{isError && (
-
- {variables}
-
-
-)}
+{
+ isError && (
+
+ {variables}
+
+
+ )
+}
```
+
[//]: # 'ExampleUI3'
### If the mutation and the query don't live in the same component
@@ -63,20 +63,22 @@ If the mutation errors, the item will also disappear. But we could continue to s
This approach works very well if the mutation and the query live in the same component, However, you also get access to all mutations in other components via the dedicated `useMutationState` hook. It is best combined with a `mutationKey`:
[//]: # 'ExampleUI4'
+
```tsx
// somewhere in your app
const { mutate } = useMutation({
mutationFn: (newTodo: string) => axios.post('/api/data', { text: newTodo }),
onSettled: () => queryClient.invalidateQueries({ queryKey: ['todos'] }),
- mutationKey: ['addTodo']
+ mutationKey: ['addTodo'],
})
// access variables somewhere else
const variables = useMutationState({
filters: { mutationKey: ['addTodo'], status: 'pending' },
- select: (mutation) => mutation.state.variables
+ select: (mutation) => mutation.state.variables,
})
```
+
[//]: # 'ExampleUI4'
`variables` will be an `Array`, because there might be multiple mutations running at the same time. If we need a unique key for the items, we can also select `mutation.state.submittedAt`. This will even make displaying concurrent optimistic updates a breeze.
@@ -122,11 +124,13 @@ useMutation({
},
})
```
+
[//]: # 'Example'
### Updating a single todo
[//]: # 'Example2'
+
```tsx
useMutation({
mutationFn: updateTodo,
@@ -158,11 +162,13 @@ useMutation({
},
})
```
+
[//]: # 'Example2'
You can also use the `onSettled` function in place of the separate `onError` and `onSuccess` handlers if you wish:
[//]: # 'Example3'
+
```tsx
useMutation({
mutationFn: updateTodo,
@@ -174,8 +180,8 @@ useMutation({
},
})
```
-[//]: # 'Example3'
+[//]: # 'Example3'
## When to use what
diff --git a/docs/react/guides/paginated-queries.md b/docs/react/guides/paginated-queries.md
index c0138ad141..7ddb8b348a 100644
--- a/docs/react/guides/paginated-queries.md
+++ b/docs/react/guides/paginated-queries.md
@@ -6,12 +6,14 @@ title: Paginated / Lagged Queries
Rendering paginated data is a very common UI pattern and in TanStack Query, it "just works" by including the page information in the query key:
[//]: # 'Example'
+
```tsx
const result = useQuery({
queryKey: ['projects', page],
- queryFn: fetchProjects
+ queryFn: fetchProjects,
})
```
+
[//]: # 'Example'
However, if you run this simple example, you might notice something strange:
@@ -29,27 +31,23 @@ Consider the following example where we would ideally want to increment a pageIn
- `isPlaceholderData` is made available to know what data the query is currently providing you
[//]: # 'Example2'
+
```tsx
-import { keepPreviousData, useQuery } from "@tanstack/react-query";
-import React from "react";
+import { keepPreviousData, useQuery } from '@tanstack/react-query'
+import React from 'react'
function Todos() {
const [page, setPage] = React.useState(0)
- const fetchProjects = (page = 0) => fetch('/api/projects?page=' + page).then((res) => res.json())
-
- const {
- isPending,
- isError,
- error,
- data,
- isFetching,
- isPlaceholderData,
- } = useQuery({
- queryKey: ['projects', page],
- queryFn: () => fetchProjects(page),
- placeholderData: keepPreviousData,
- })
+ const fetchProjects = (page = 0) =>
+ fetch('/api/projects?page=' + page).then((res) => res.json())
+
+ const { isPending, isError, error, data, isFetching, isPlaceholderData } =
+ useQuery({
+ queryKey: ['projects', page],
+ queryFn: () => fetchProjects(page),
+ placeholderData: keepPreviousData,
+ })
return (