feat(useAxios): Add types and callback to handle AxiosError

[michaelcozzolino]

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

⚠️ Slowing down new functions

Warning: Slowing down new functions

As the VueUse audience continues to grow, we have been inundated with an overwhelming number of feature requests and pull requests. As a result, maintaining the project has become increasingly challenging and has stretched our capacity to its limits. As such, in the near future, we may need to slow down our acceptance of new features and prioritize the stability and quality of existing functions. Please note that new features for VueUse may not be accepted at this time. If you have any new ideas, we suggest that you first incorporate them into your own codebase, iterate on them to suit your needs, and assess their generalizability. If you strongly believe that your ideas are beneficial to the community, you may submit a pull request along with your use cases, and we would be happy to review and discuss them. Thank you for your understanding.

---

Description

This PR introduces a generic type system for the AxiosError, in detail:

• When an Error is thrown by axios we cannot ensure that it is an AxiosError, so I added an axiosError ref that will be populated only when the Error is an instance of AxiosError, furthermore when the error is not AxiosError, the error ref will still be populated, and I also added a callback (onAxiosError) that will be executed only when we have an AxiosError, if that is the case, also the onError callback will be executed.
• Now that we have the AxiosError, basically, according to me, the developer is mainly looking for the data property of the error response, and, also for consistency with the data property of a successful AxiosResponse, I added a computed property axiosErrorResponseData that returns exactly the data of the error response.

Example usage

// Some utility types
type DefaultStrictUseAxiosReturn<Response, Payload = unknown, AxiosErrorResponse = unknown> = StrictUseAxiosReturn<
    Response,
    AxiosResponse<Response>,
    Payload,
    AxiosErrorResponse,
    UseAxiosOptionsWithInitialData<Response>
>

export type PromiseLikeStrictUseAxiosReturn<Response, Payload = unknown, AxiosErrorResponse = unknown> =
    Promise<DefaultStrictUseAxiosReturn<Response, Payload, AxiosErrorResponse>>
    & DefaultStrictUseAxiosReturn<Response, Payload, AxiosErrorResponse>

interface MyResponse {
    id: number,
    name: string
}

interface MyPayload {
    name: string
}

interface ErrorResponse {
    errors: { name: string[] }
}

function updateApiData(options: UseAxiosOptionsWithInitialData<MyResponse, ErrorResponse>): PromiseLikeStrictUseAxiosReturn<MyResponse, MyPayload, ErrorResponse> {
    return useAxios(
        '/something',
        { method: 'put' },
        options,
    )
}

const { execute, axiosError, axiosErrorResponseData, data } = updateApiData({
    initialData: { id: 1, name: 'Michael' },
  onAxiosError: (e) => {
    console.log(e?.response?.data.errors.name)
  },
})

Additional context

If the feature is accepted, I will add tests and update the docs. There is no breaking change in the composable, but only in the types, as it seems unavoidable.
Let me know if the naming is fine, I think they are pretty descriptive, but I'm looking forward to suggestions, if any.

[michaelcozzolino]

@antfu @OrbisK any feedback?

[OrbisK]

this type is breaking

[michaelcozzolino]

it's unavoidable, do you have any suggestions to make it non breaking?