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
Copy file name to clipboardExpand all lines: docs/rtk-query/usage-with-typescript.mdx
+181Lines changed: 181 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -497,3 +497,184 @@ function MaybePost({ id }: { id?: number }) {
497
497
return <div>...</div>
498
498
}
499
499
```
500
+
501
+
## Type safe error handling
502
+
503
+
When an error is gracefully provided from a [`base query`](./api/createApi.mdx#baseQuery), RTK query will provide the error
504
+
directly. If an unexpected error is thrown by user code rather than a handled error,
505
+
that error will be transformed into a `SerializedError` shape. Users should make sure that they are checking which kind of error they are dealing with before attempting to access its properties. This can be done in a type safe manner either
506
+
by using a type guard, e.g. by checking for [discriminated properties](https://www.typescriptlang.org/docs/handbook/2/narrowing.html#the-in-operator-narrowing),
507
+
or using a [type predicate](https://www.typescriptlang.org/docs/handbook/2/narrowing.html#using-type-predicates).
508
+
509
+
When using [`fetchBaseQuery`](./api/fetchBaseQuery.mdx), as your base query,
510
+
errors will be of type `FetchBaseQueryError | SerializedError`. The specific shapes of those types can be seen below.
511
+
512
+
```ts title="FetchBaseQueryError type"
513
+
exporttypeFetchBaseQueryError=
514
+
| {
515
+
/**
516
+
* * `number`:
517
+
* HTTP status code
518
+
*/
519
+
status:number
520
+
data:unknown
521
+
}
522
+
| {
523
+
/**
524
+
* * `"FETCH_ERROR"`:
525
+
* An error that occurred during execution of `fetch` or the `fetchFn` callback option
526
+
**/
527
+
status:'FETCH_ERROR'
528
+
data?:undefined
529
+
error:string
530
+
}
531
+
| {
532
+
/**
533
+
* * `"PARSING_ERROR"`:
534
+
* An error happened during parsing.
535
+
* Most likely a non-JSON-response was returned with the default `responseHandler` "JSON",
536
+
* or an error occurred while executing a custom `responseHandler`.
537
+
**/
538
+
status:'PARSING_ERROR'
539
+
originalStatus:number
540
+
data:string
541
+
error:string
542
+
}
543
+
| {
544
+
/**
545
+
* * `"CUSTOM_ERROR"`:
546
+
* A custom error type that you can return from your `queryFn` where another error might not make sense.
547
+
**/
548
+
status:'CUSTOM_ERROR'
549
+
data?:unknown
550
+
error:string
551
+
}
552
+
```
553
+
554
+
```tstitle="SerializedError type"
555
+
exportinterfaceSerializedError {
556
+
name?:string
557
+
message?:string
558
+
stack?:string
559
+
code?:string
560
+
}
561
+
```
562
+
563
+
### Error result example
564
+
565
+
When using `fetchBaseQuery`, the `error` property returned from a hook will have the type `FetchBaseQueryError | SerializedError | undefined`.
566
+
If an error is present, you can access error properties after narrowing the type to either `FetchBaseQueryError` or `SerializedError`.
567
+
568
+
```tsx
569
+
import { api } from'./services/api'
570
+
571
+
function PostDetail() {
572
+
const { data, error, isLoading } =usePostsQuery()
573
+
574
+
if (isLoading) {
575
+
return <div>Loading...</div>
576
+
}
577
+
578
+
if (error) {
579
+
if ('status'inerror) {
580
+
// you can access all properties of `FetchBaseQueryError` here
0 commit comments