Replies: 1 comment
-
in v4,
yes, that's what I would do. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Recently (?) useQuery logs a console error when the
queryFn
returnsundefined
:I can set a breakpoint here and log
this
and looking at the query key I can figure out which call was it.Up till now, I used undefined to return "Not found" type of results. Like,
getDetailsById(id: string | null | undefined)
and returnundefined
if the id is missing or the API not found anything by that particular id. This is convenient, because later I can just useif (!details) ...
to check missing data. This is not a problem for array type of results, there I can just return[]
.If I am forced to return something else, I would need to do a type check every time.
Maybe I could use
null
and return it instead ofundefined
, but later it could also be included in the condition, so I am wondering what would be the best practice here? Should I always throw an error in such cases?Beta Was this translation helpful? Give feedback.
All reactions