Define useFetch behavior

[userquin]

@wheatjs @antfu @benlesh @isgj

Can we do a little effort to close the useFetch functioning? I know we are all very busy with other projects, but this subject is taking more than 10 days to just only define its behavior (we have disparate behaviors on #549, I'm suggesting using raw objects instead fetch ones, others requesting removing the raw object encoding and also the content-type header handling on multipart requests)...

I can remove all logic to encode raw objects to build the request body and also remove the content-type header handling and just keep the original logic, only adding the content type when necessary.
The stopper here was the payloadType option since is forcing us to deal with it, but removing the content-type header that handles the issue it goes away.

Problems to be resolved:

• using raw objects or just using fetch ones: you can see some examples here and here. Raw objects can be used to change the encoding without rewriting the logic: for example, switching between application/json and application/x-www-form-urlencoded is just switch the payloadType option without rewriting the logic to encode the object while using just fetch ones we will need to change also the object itself we are sending.
• try to correct invalid options from user options: deal with multipart header if present. You can see the problem here.
• access to the payload on error: see proposal on refactor(useFetch): change internal logic #549 for responseHandler and CustomResponseContext type here and here respectivelly.

[wheatjs]

I'm currently working on a PR for this. I've been looking at how other popular libraries have done things and am going to follow what they do. Currently following what use-http does as they have already addressed many of the issues we are currently having. https://github.com/ava/use-http [see their implementation for handling headers here]

[benlesh]

If I might make a suggestion: it's a noble goal to try to make useFetch cover everyone's use cases, however, I think it's in the best interest of the ecosystem to make as many of the features as tree-shakeable as possible. A collection of composition-based utilities. Even the useHttp example is a bit heavy, IMHO. People should only pay for what they use.

Sorry for butting my head in. This isn't my library. Just an area of interest for me.

What you're working on here could well be one of the most important and most used utilities in the Vue ecosystem. The weight of the design is as important as the features, for sure.

[wheatjs]

If I might make a suggestion: it's a noble goal to try to make useFetch cover everyone's use cases, however, I think it's in the best interest of the ecosystem to make as many of the features as tree-shakeable as possible. A collection of composition-based utilities. Even the useHttp example is a bit heavy, IMHO. People should only pay for what they use.

Sorry for butting my head in. This isn't my library. Just an area of interest for me.

What you're working on here could well be one of the most important and most used utilities in the Vue ecosystem. The weight of the design is as important as the features, for sure.

I don't mind at all and do appreciate the input. When I was mentioning doing what useHttp does, I mostly just meant the headers and body part. Do you think that would be too much? Please feel free to speak your mind, any input is greatly appreciated

[antfu]

I personally would like to keep this function as simple as possible. It's more like, if you want to fetch something quickly, we already provided out-of-box. For more complex cases, they should use axios, ky or whatever they want with more mature and well-rounded implementations. Otherwise, a separate package like @vueuse/fetch would be better, but I would also doubt if it's worth to do given there is already many lib doing great jobs on this.

[wheatjs]

Since it looks like we would all like to keep useFetch pretty simple, perhaps we can remove the portion of useFetch that sets the request content-type and modifies the post data. This would end up being a breaking change, but might be the best option as we can avoid giving the wrong idea of this being a replacement for something like axios and we can keep the function minimal. I'm not not a big fan of having something like @vueuse/fetch as I think we are all pretty busy and it would be just another thing to maintain.

[isgj]

Yesterday I made a PR #573

It sets the content type only if no content type is given and the payload is object. The API doesn't change and it will work also with other types for which before the content type was set as text.

It handles only the case json so also the payload is stringified because (probably) it's the most used case. For the rest it proxies to fetch

[mariusa]

As a newcomer, I thought useFetch was a replacement for axios. Would you please clarify the intended use case and make some recommendations at https://vueuse.org/core/usefetch/ ?

Also, coming from axios, I was expecting the possibility to use await, eg

let response = await axios.get('/api/auth/session')
console.log(response.data) //when reaching this line, data is set. Errors are handled in interceptor. Headers are set in interceptor.

How can one use useFetch in a similar, simple way? None of the given examples use await, so how does one simply get the data without additional code?

[userquin]

In your example, move the for loop inside the watch and use newData instead data.

[userquin]

the data type on data ref may be text, json, blob... see the docs.

[mariusa]

I see, thanks for clarification! It makes sense, but it's more complex than await. I'll stick to axios.

[isgj]

@manaust in your case the bare fetch is the option.

useFetch was explained before and it's use case, but in my use cases when I wanted to do something after the call was finished I did it like so

const { isFetching, data, execute } = useFetch('/', { immediate: false }) // you can add other config like .jaon()

// when it makes sense to make the call and await
await execute() // if you use POST method you can do: await post({...}).execute()
myProccessData(data) // here you have access to data and all the rest

if you don't need to show the state of the call(or handle it manually) just use axios or fetch, in my case I wanted to show loading state and await for the call

[isgj]

((oops I mentioned the wrong user))