useFetch: [Feature request] Expose whole the http response on error (in onFetchError)

[red010182]

Please consider expose the whole http response in onFetchError.

e.g. ctx.error.response (like axios did)

Currently, there's nothing useful in ctx of onFetchError, I can't even get status code nor url.
It's really hard to customize a useful error handler middleware without key information.

const fetcher = createFetch({
  baseUrl: 'http://localhost:5678/',
  options: {
    async onFetchError(ctx) {
      // only ctx.data and ctx.error
      // can't get status code, request url or request parameters
      console.error(ctx) 
      return ctx
    },
  },
})

Feature request:

ctx.error.response = { ... } // http response object, contains status code, url, parameters...

[Delicious-Bacon]

I would like to point out one thing that I noticed.

Like you mentioned, right now, we only have ctx.data and ctx.error available in the onFetchError interceptor, which are not of much use apart from mutating them. I guess that this interceptor is only used for setting default fallbacks to the data.

But the afterFetch interceptor has both the response and data properties in the ctx (source code):

ctx: {
  response,
  data
}

While the onFetchError interceptor triggers only on errors, the afterFetch interceptor should trigger on any fetch response, even those with error codes, but the documentation only says The afterFetch option can intercept the response data before it is updated. (Documentation)

I would say we're supposed to utilize our handlers in afterFetch interceptor since it has the needed information, and it triggers on server responses (the onFetchError interceptor triggers whenever there is error, so it would trigger when the server is down, for example).

An example of afterFetch interceptor:

const fetcher = createFetch({
  // baseUrl: '...',
  options: {
    afterFetch({ response }) {
      const { status, url } = response;

      if (status === 200) {
        console.log('Successfully fetched data @:', url);
      } else if (status === 404) {
        console.log('404 not found @:', url);
      }
    },
  },
  fetchOptions: {
    // ...options
  },
});

[red010182]

Thanks. This may be a workaround for now. It would be convenient to get response (especially status code and url) in onFetchError for me.

[wheatjs]

Going to reopen this as I would like to include it. I'll see if I can get around to it soon

[Ragura]

@Delicious-Bacon, you should note that the documentation states that afterFetch() is only run on 2xx status codes, not after each fetch (currently has an open pull request to correctly implement this (#1266)). This makes it even more important to have access to the extra data such as the status code in the ctx argument of onFetchError(), because errors shouldn't even appear in the afterFetch() hook.

[Glandos]

It seems that the design of afterFetch and onFetchError is confusing. Issues raised in #553 and #526 are similar to this one, and were "fixed" by #572 that move the error after the call to afterFetch, leading to calling it on every requests, even failed ones.

Then, #1266 was opened because the "doc" was not matching the code, but the PR #1271 linked to this kind of revert #572, since it checks the status code and doesn't call afterFetch. My best guess was that the code was right and the "doc" should have been updated in #572.

And now, we all have the same issue: we need to have the full response to do some useful interceptions. So we can either:

• Call afterFetch everytime. After all, the HTML documentation doesn't talk about errors in afterFetch workflow. It was only the JSDoc that mentionned it.
• Enhance onFetchError and give the response.

I don't have strong opinions on this. But we need one of those.