fix(useFetch)!: allow setting response type before doing request

[isgj]

fixes #442

Now there is only one interface UseFetchReturn that is returned, when you call useFetch the first time, set the method or update the type. Of course you cannot change the method or the type while it's making a request.

In addition this fixes (unless it was intended) the loading state when the request is cancelled in beforeFetch .

I didn't touch the tests nor the docs. before let me know what you think about this approach.

[antfu]

I still not quite understand the context here. useFetch is designed to be used for one response type at once. Which gives better code organization and better typescript support. For requests that need to have difference types on each call, I'd think it's better to use two separate useFetch to do that

[isgj]

useFetch is designed to be used for one response type at once.

This is still true, you can't change the type nor the method (and data) while making a call.

More than different types, this is about different data as explained in the linked issue. I can update this PR so for the functions that set the type the returned interface is base + method functions (but it wont change much).

[wheatjs]

I think this should still be !initalized, right? Changing the payload seems fine to me, but we don't want to change the type.

[isgj]

In this PR initialized is not used. It was set to true the first time execute was called and stayed so.
Now in master now you can do

const {post} = useFetch(..., {immediate: false})
// somewhere else
post(...).json().execute() // of course only once

If you'll allow more calls json will return undefined and you cannot chain execute and ... (you got the idea).

In the last commit I changed the types so you can do

const {post} = useFetch(..., {immediate: false}).json()
// somewhere else
post(...).execute() // even more times

To note

This is a breaking change as now the order you chain the method is strict post -> json (method --> type), here instead is the inverse json --> (post X times).
If the order shouldn't be strict then those functions should return the same interface, otherwise keeping track what was called and should be returned would be unnecessary

[antfu]

I see. That's a good point. Since it's a breaking change, I'd more like to have it in the v5 release #363. Will handle it soon

[schelmo]

👍
the next cool thing would be refetching when the the payload is changing!
like

const payload = ref({some: 'data'})
useFetch('/', {refetch: true}).post(payload)
payload.value.more = 'moar' // -> refetches

maybe even watch the whole config object? (so, changes to type, method, payload, payloadType will trigger a refetch)

[wheatjs]

👍
the next cool thing would be refetching when the the payload is changing!
like

const payload = ref({some: 'data'})
useFetch('/', {refetch: true}).post(payload)
payload.value.more = 'moar' // -> refetches

maybe even watch the whole config object? (so, changes to type, method, payload, payloadType will trigger a refetch)

Hmm probably would just want to watch the payload for refetching. I don't think we really want to be changing methods

[isgj]

Hmm probably would just want to watch the payload for refetching.

I agree. And resending some data with POST (or PUT, ...) you're not refetching but changing something on the server.