dulnan
[Feature request] Make `useGraphqlQuery` not throwing (similar to `useFetch`)
Hi! So currently, I was using useFetch, which is non-throwing, meaning that if a HTTP request fails (e.g. not found, or whatever), it will still continue. This allows you to do:
const { data, error } = await useFetch('/api/example')
if (error.value) {
throw createError({ statusCode: 500, message: 'Error fetching author details', fatal: true })
}
With the useGraphqlQuery though, the page returns with error 500, no way to catch it. I could wrap it inside a useAsyncData and a try/catch but I guess it would be nicer if the composable would act like nuxts composables.
What do you think?
Interesting idea. I‘m always using it inside useAsyncData in page components. In plugins or middlewares I mostly don‘t catch the errors on purpose and handle them globally. But that‘s just because of my setups where the data must be present or else the entire app becomes "useless" 😄. But that‘s just me.
I like the idea and can see how it might be useful to most potential users. And it should likely be the default behavior, with a possible option that can be passed as a third argument to disable the behavior for specific cases.
Looking into it now. What would be a good way to catch the errors and provide them in the return value? data and errors are both connected to the specific query/mutation.
With an invalid query name the module's server handler will throw a 400 error. If the GraphQL endpoint is unreachable, the result will be a 500 fetch error.
Should such errors be included in the errors array? I'm not sure about that, because errors is specific to GraphQL. I'd have to return a third property, fetchError or something like that. But then you'd have to check both errors and fetchError to determine if any errors happened.
Currently it's possible to define a custom onServerError method where one can catch such errors and handle them, for example by returning { data: null, errors: [...] } there as a 200. This would result in the module not throwing an error (unless something client-side goes wrong, of course).
But thanks to your input I realized that the return type is not correct: It's missing the errors property!
Yeah I realize it's more complicated than with useFetch, which just holds a generic error about what went wrong with the fetch. I was also moving all my useGraphqlQuery inside useAsyncData and it's working pretty well. Given the fact that there is this native GraphQL errors array which comes in with a request, maybe it's the right thing that this method throws and you should catch it inside a useAsyncData. My initial idea was just that people could swap out useFetch with useGraphqlQuery 1:1