Scalable Interceptor Arguments, responseType option
Scalable Interceptor Arguments
🚨🚨THIS RELEASE CONTAINS BREAKING CHANGES!!! 🚨🚨
Due potential future scalability issues such as adding new items to pass to the interceptors, we're changing it to an object destructuring syntax instead of multiple arguments.
useFetch({
interceptors: {
request: async (options, url, path, route) => {},
response: async (response) => {}
}
}
will now be
useFetch({
interceptors: {
request: async ({ options, url, path, route }) => {}, // <- notice object destructuring
response: async ({ response }) => {} // <- notice object destructuring
}
}
This provides a few benefits.
- we can now add new options to these callbacks without having breaking changes
- we can pull out these options in whatever order so we don't have unused variables
For example, let's say in the future we want to do
useFetch({
interceptors: {
request: async ({ options, route, attempt }) => {
// now we can add a new field `attempt`
// and we can just grab `route` without `url` and `path`
},
response: async ({ response, attempt }) => {
// now we can add a new field `attempt`
}
}
}
responseType
option
This will determine how the data
field is set. If you put json
then it will try to parse it as JSON. If you set it as an array, it will attempt to parse the response
in the order of the types you put in the array. Read about why we don't put formData
in the defaults in the yellow Note part here.
Defaults to: ['json', 'text', 'blob', 'readableStream']
useFetch({
// this would basically call `await response.json()`
// and set the `data` and `response.data` field to the output
responseType: 'json',
// OR can be an array. It's an array by default.
// We will try to get the `data` by attempting to extract
// it via these body interface methods, one by one in
// this order. We skip `formData` because it's mostly used
// for service workers.
responseType: ['json', 'text', 'blob', 'arrayBuffer'],
})