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
{{ message }}
Repository navigation
Commit 4e45d7c
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: docs/framework/solid/quick-start.md
+11-11Lines changed: 11 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,14 +11,14 @@ The `@tanstack/solid-query` package provides a 1st-class API for using TanStack
11
11
import {
12
12
QueryClient,
13
13
QueryClientProvider,
14
-
useQuery,
14
+
createQuery,
15
15
} from'@tanstack/solid-query'
16
16
import { Switch, Match, For } from'solid-js'
17
17
18
18
const queryClient =newQueryClient()
19
19
20
20
function Example() {
21
-
const query =useQuery(() => ({
21
+
const query =createQuery(() => ({
22
22
queryKey: ['todos'],
23
23
queryFn: fetchTodos,
24
24
}))
@@ -53,7 +53,7 @@ function App() {
53
53
54
54
Solid Query offers useful primitives and functions that will make managing server state in SolidJS apps easier.
55
55
56
-
-`useQuery`
56
+
-`createQuery`
57
57
-`createQueries`
58
58
-`createInfiniteQueries`
59
59
-`createMutation`
@@ -67,7 +67,7 @@ Solid Query offers useful primitives and functions that will make managing serve
67
67
68
68
Solid Query offers an API similar to React Query, but there are some key differences to be mindful of.
69
69
70
-
- Arguments to `solid-query` primitives (like `useQuery`, `createMutation`, `useIsFetching`) listed above are functions, so that they can be tracked in a reactive scope.
70
+
- Arguments to `solid-query` primitives (like `createQuery`, `createMutation`, `useIsFetching`) listed above are functions, so that they can be tracked in a reactive scope.
71
71
72
72
```tsx
73
73
// ❌ react version
@@ -77,7 +77,7 @@ useQuery({
77
77
})
78
78
79
79
// ✅ solid version
80
-
useQuery(() => ({
80
+
createQuery(() => ({
81
81
queryKey: ['todos', todo],
82
82
queryFn: fetchTodos,
83
83
}))
@@ -89,7 +89,7 @@ useQuery(() => ({
89
89
import { For, Suspense } from'solid-js'
90
90
91
91
function Example() {
92
-
const query =useQuery(() => ({
92
+
const query =createQuery(() => ({
93
93
queryKey: ['todos'],
94
94
queryFn: fetchTodos,
95
95
}))
@@ -112,7 +112,7 @@ function Example() {
112
112
import {
113
113
QueryClient,
114
114
QueryClientProvider,
115
-
useQuery,
115
+
createQuery,
116
116
} from'@tanstack/solid-query'
117
117
import { Match, Switch } from'solid-js'
118
118
@@ -137,7 +137,7 @@ function Example() {
137
137
// })
138
138
139
139
// ✅ solid version -- does not support destructuring outside reactive context
The reason why `useQuery` accepts a function that returns an object is to allow for reactive options. This is useful when query options depend on other values/signals that might change over time. Solid Query can track the passed function in a reactive scope and re-run it whenever the dependencies change.
107
+
The reason why `createQuery` accepts a function that returns an object is to allow for reactive options. This is useful when query options depend on other values/signals that might change over time. Solid Query can track the passed function in a reactive scope and re-run it whenever the dependencies change.
`useQuery` supports triggering SolidJS `Suspense` and `ErrorBoundary` components when the query is in a pending or error state. This allows you to easily handle loading and error states in your components.
154
+
`createQuery` supports triggering SolidJS `Suspense` and `ErrorBoundary` components when the query is in a pending or error state. This allows you to easily handle loading and error states in your components.
Solid Query uses a [discriminated union type](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes-func.html#discriminated-unions) for the query result, discriminated by the `status` field and the derived status boolean flags. This will allow you to check for e.g. `success` status to make `data` defined:
68
68
69
69
```tsx
70
-
const query =useQuery(() => ({
70
+
const query =createQuery(() => ({
71
71
queryKey: ['number'],
72
72
queryFn: () =>Promise.resolve(5),
73
73
}))
@@ -85,7 +85,7 @@ if (query.isSuccess) {
85
85
The type for error defaults to `Error`, because that is what most users expect.
86
86
87
87
```tsx
88
-
const query =useQuery(() => ({
88
+
const query =createQuery(() => ({
89
89
queryKey: ['groups'],
90
90
queryFn: fetchGroups,
91
91
}))
@@ -99,7 +99,7 @@ query.error
99
99
If you want to throw a custom error, or something that isn't an `Error` at all, you can specify the type of the error field:
Similarly to registering a [global error type](#registering-a-global-error) you can also register a global `Meta` type. This ensures the optional `meta` field on [queries](../useQuery) and [mutations](../createMutation) stays consistent and is type-safe. Note that the registered type must extend `Record<string, unknown>` so that `meta` remains an object.
156
+
Similarly to registering a [global error type](#registering-a-global-error) you can also register a global `Meta` type. This ensures the optional `meta` field on [queries](../createQuery) and [mutations](../createMutation) stays consistent and is type-safe. Note that the registered type must extend `Record<string, unknown>` so that `meta` remains an object.
If you inline query options into `useQuery`, you'll get automatic type inference. However, you might want to extract the query options into a separate function to share them between `useQuery` and e.g. `prefetchQuery`. In that case, you'd lose type inference. To get it back, you can use `queryOptions` helper:
175
+
If you inline query options into `createQuery`, you'll get automatic type inference. However, you might want to extract the query options into a separate function to share them between `createQuery` and e.g. `prefetchQuery`. In that case, you'd lose type inference. To get it back, you can use `queryOptions` helper:
0 commit comments