Vueuse Usefetch

Posted on  by admin

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 #549 for responseHandler and CustomResponseContext type here and here respectivelly.

Replies

ยท

Jun 11, 2021
Collaborator

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]

2 replies

Jun 11, 2021

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.

Jun 11, 2021

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

Jun 11, 2021
Maintainer

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.

2 replies

Jun 11, 2021

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.

Jun 11, 2021

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

Jun 15, 2021

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

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?

8 replies

Jun 16, 2021

@mariusauseFetch uses the reactivity system (composition api) and so you don't need to use await since it will be done by the useFetch function, you get a ref to the response body, along other refs to know if the useFetch is fetching, has finished, has error...:

You can see the demo.vue file on this repo or link from footer page on docs.

Jun 16, 2021

Thanks. Let's consider the use case that one wants to process retrieved data, right after retrieval:

This won't work, as data isn't set yet (?). One has to wait for fetch to complete.

How should one handle this? Have continuous a loop to check if isFinished is set? (ugly)

Jun 16, 2021
Author

useFetch is the composable hook for setup, that will register all stuff, and so you only need to add a watch for data ref (since it is a ref you need to use data.value (on watch there is no need):

In the original example, it is fetching async (is feching asap), since immediate is true by default (I'm not 100% sure), you will get the response once the fetch finish.

You can see a playground here

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment