blog/status-checks-in-react-query #60
Replies: 19 comments 1 reply
-
Amazing advice, thanks for your article ! Depending on the use case it will bring a far superior UX for our users. 🥳 |
Beta Was this translation helpful? Give feedback.
-
Thank you for such good blogs. Where can i find those situations where the second pattern of status checking is harmful, I'm curious. |
Beta Was this translation helpful? Give feedback.
-
@seanbruce we discussed this a lot on this PR: TanStack/query#1108 (comment) |
Beta Was this translation helpful? Give feedback.
-
Thanks a lot for all your react queries articles, they’re are amazing, I just read them all :) |
Beta Was this translation helpful? Give feedback.
-
What can I say ... the job you've done with this series is just amazing. Thank you so much for sharing! |
Beta Was this translation helpful? Give feedback.
-
Thank you! One thing worth mentioning is that the final form of checks is more TypeScript-friendly. Compiler is not smart enough to figure out that
|
Beta Was this translation helpful? Give feedback.
-
@ivan-kleshnin in your Example, you would still need to check for |
Beta Was this translation helpful? Give feedback.
-
Yes. I gave it more thought and documented my preferences here: https://gist.github.com/ivan-kleshnin/b98c6be12ed0b05e6cde186e4deeedb7 Your Example-1 (classic) suffers from Error overriding the data as you mentioned. I'd start with separating 2 different UX approaches: inline and block loaders. Block loaders are simple Then I'd review the following 4 cases which cover most patterns I can think of. Case-1
Case-2
Case-3
Case-4
And the following two implementations seem to fullfill the above assertions: // INLINE LOADERS (multiple placeholder-like loaders)
export function SomeControllerWithInlineLoading() : JSX.Element {
const todosResp = useQuery()
return <>
{todosResp.error &&
<Error/>
}
{(todosResp.data || todosResp.isLoading) && <Something
data={todosResp.data}
/>}
</>
}
type SomethingProps = {
data ?: Data
}
function Something({data} : SomethingProps) : JSX.Element {
return <div>
Foo: {data.foo ? data.foo : "..."}
Bar: {data.bar ? data.bar : "..."}
</div>
}
// BLOCK LOADER (one widget-level loader)
export function SomeControllerWithBlockLoading() : JSX.Element {
const todosResp = useQuery()
return <>
{todosResp.error &&
<Error/>
}
{todosResp.isLoading &&
<Loading/>
}
{todosResp.data && <SomethingElse
data={todosResp.data}
/>}
</>
} The above closely follows the code structure I use for If we want to render |
Beta Was this translation helpful? Give feedback.
-
@ivan-kleshnin yes, that looks good. I think the I've also entertained the approach of showing toast notifications for errors only for background errors via the global onError callback. If you have data already and get an error, the toast is shown. That way, you can still do the early return that you get with |
Beta Was this translation helpful? Give feedback.
-
@TkDodo thank you. It's certainly one of solutions a developer has to consider. In such case I'd probably go for positioned floating alerts – when it's
True. But then we often have to repeat the "wrapping" markup like:
vs
And |
Beta Was this translation helpful? Give feedback.
-
@TkDodo another issue that, in my opinion, makes early return a disaster is the following: the primary goal of an early return is to avoid unnecessary code execution. Unless doing it completely wrong, most of the actual computation in react render functions happens in hooks, and react hooks, being reliant on order of execution for change detection, cannot be called conditionally and obviously a return statement before makes it conditional. |
Beta Was this translation helpful? Give feedback.
-
I think it is mainly for developers so that they don't have to think about a certain case further down, and it also helps TypeScript to narrow types.
if your component is 50% hooks calls and 50% markup creation, I would strongly advise to extract the first 50% into a custom hook to separate the logic from your markup. See also: https://tkdodo.eu/blog/simplifying-use-effect#3-write-custom-hooks |
Beta Was this translation helpful? Give feedback.
-
It seems that https://react-query-beta.tanstack.com/guides/disabling-queries In the end I just bypassed React Query and repeated calculation for // in component
const { data: post, isLoading } = usePost(id);
const isEnabled = !isNaN(id); // repeat calculation
// usePost query hook
export const usePost = (id: number) => {
const query = useQuery<PostWithAuthor, AxiosError>(
[QueryKeys.POST, id],
() => getPost(id),
{
enabled: !isNaN(id), // disable query
}
);
return query;
}; |
Beta Was this translation helpful? Give feedback.
-
a query is in
That would be the direct equivalent to the old It was one of the trade-offs to make this one case (you have no data and start a query disabled) a bit more verbose to check. However, you can also reverse check and show loading at the end. I'm showing this pattern here: https://tkdodo.eu/blog/status-checks-in-react-query
one thing to keep in mind, even with the v3, is that the
this query will be in |
Beta Was this translation helpful? Give feedback.
-
This is AWESOME! I think this should be the default way of handling data state in the React Query example, e.g. in this page, because by default React Query uses background refetch and people who just learn React Query won't be aware of this issue |
Beta Was this translation helpful? Give feedback.
-
Thanks for your article. It's help me a lot. 😉 |
Beta Was this translation helpful? Give feedback.
-
Awesome blogs. Thanks! |
Beta Was this translation helpful? Give feedback.
-
I've been searching in your blog about the differences between isFetching and isLoading. I found some explanation in the Offline React Query, but was not really clear the use cases. Thank you! |
Beta Was this translation helpful? Give feedback.
-
I notice the documentation (https://tanstack.com/query/latest/docs/framework/react/guides/queries) says
which seems to contradict the above:
I'm only at the beginning of my react-query journey but from what I can see, the latter is the approach I'm going to use. |
Beta Was this translation helpful? Give feedback.
-
Status Checks in React Query | TkDodo's blog
How the wrong status check order can negatively impact user experience
https://tkdodo.eu/blog/status-checks-in-react-query
Beta Was this translation helpful? Give feedback.
All reactions