Add some features from useFetch also to useAxios

[sethidden]

Currently useFetch has execute(), but useAxios does not. This means that with useFetch you can first create useFetch, set {immediate: false}, then execute() the call later, but with useAxios it fires immediately when you call useAxios.

Abort is also missing in useAxios.

Some properties don't make sense to add into axios such as statusText (since that's just in the axios response).

Another thing is that the returned property names are different in useAxios and useFetch, but changing that'd be a breaking change.

Exposed logic from both logics:

useAxios

  response: Ref<AxiosResponse<T> | undefined>
  data: Ref<T | undefined>
  finished: Ref<boolean>
  loading: Ref<boolean>
  canceled: Ref<boolean>
  error: Ref<AxiosError<T> | undefined>

useFetch

  isFinished: Ref<boolean>
  statusCode: Ref<number | null>
  response: Ref<Response | null>
  error: Ref<any>
  data: Ref<T | null>
  isFetching: Ref<boolean>
  canAbort: ComputedRef<boolean>
  aborted: Ref<boolean>
  abort: Fn
  execute: () => Promise<any>

[sethidden]

Or perhaps it's better to just use https://vueuse.org/core/useAsyncState/ for requests in general?

[lstoeferle]

Hey @3nuc,

I would love to see the execute() logic in useAxios too. AFAIK there is already an option to cancel request in useAxios (I can remember me adding it).

But I don't see any value in introducing breaking changes while refactoring the return type to match useFetch. IMO there are only a few rare cases, where somebody is using axios besides the fetch api and vice versa. Typically you only use one of both, which eliminates the risk of mixing the return types of useAxios and useFetch.

Feel free to open a PR 😉

Kind regards,
Lukas

[antfu]

Would love to align those interfaces. We can make aliases and for APIs and mark some as deprecated. Then drop them in along with the next major.

[wheatjs]

Which one are we looking to align against? Make useAxios align with the useFetch interface or useFetch align with the useAxios interface?

[antfu]

Aligning with useFetch looks better to me

[wheatjs]

Sounds good, I'll make a PR sometime this week!

[raphaelsaunier]

Thanks a lot for starting to work on this @wheatjs!

Supporting { immediate: false } and execute() would make a lot of sense in situations where you want to trigger the request conditionally while still having access to the various properties exposed by useAxios in your setup method.

In your PR description you mention that you'd like to avoid adding more overrides or other config options. As far as I can tell, this could simply be done in an additive way with the existing and optional immediate property, right? I'm not very familiar with the project so maybe I'm missing an obvious limitation.

[w20k]

Thanks a lot for a great library!

Supporting beforeFetch, afterFetch and a new one that I've added - afterFetchFail would be a great addition to useAxios. For now in my dev project those are hacks that I've added to an existing method - useAxios.

My main goal is to separate store logic and UI, and build a simple optimistic update flow with an option to update (mutate) store in a callback function, even if the main caller was closed (in my case a parent popup).