Ability to set global options on data fetching composabkes

[then3rdman]

Describe the feature

Often it is needed that you need to add a specific header or some other specific thing on all requests made to a specific domain.

So this feature would allow a user to set these global options as part of the nuxt config. Similar to how axios allows you set global options and interceptors.

The level of granularity or complexity of these options would be a matter discussion.

Additional information

• [X] Would you be willing to help implement this feature?
• [ ] Could this feature be implemented as a module?

Final checks

• [X] Read the contribution guide.
• [X] Check existing discussions and issues.

[danielroe]

Within the Vue part of your app, you can create a custom composable.

export const useMyApi = (url, options) => useFetch(url, {
  // your defaults
  key: url,
  ...options
})

You can also do something similar with the $fetch helper.

import { $fetch } from 'ohmyfetch'

export const $api = $fetch.create({
  // your default options
})

[then3rdman]

Yeh thats what I am curre tly doing but thought it felt like something that Nuxt could provide as a built in

[Luffyyy]

I agree. It definitely is possible to just make composables, but it definitely doesn't hurt adding options so people don't have to do that. There are several reasons against way:

• No autokeys
• Less consistent, I'd have to explain my composables to any other developer instead of telling them to read the nuxt docs.
• Nightmare to type properly sometimes (based on my experience)

I don't see why we can't have a way to configure (from the nuxt config) the default config. Similarly to how it was done in the axios module.

[pi0]

I think we can track factory pattern in #7026.

[pi0]

I don't see why we can't have a way to configure (from the nuxt config) the default config. Similarly to how it was done in the axios module.

@Luffyyy I can understand the benefits of it as the creator of axios module. Global options main usecase were baseURL handling specially for SSR routes. But since with Nuxt 3 we support direct $fetch in server without base URL, it is not relevant anymore. On your points:

No autokeys

We might support via https://github.com/nuxt/framework/issues/7026 or revert back to generating keys based on request (#6632) without auto key for useFetch

Less consistent, I'd have to explain my composables to any other developer instead of telling them to read the nuxt docs.

Exactly it makes behavior more consistent when you have explicitly named custom fetch instance. With axios module, a module depending on $axios could be easily broken with user-defined global options .

Nightmare to type properly sometimes (based on my experience)

Can you please elaborate more? Composables should be auto typed and indeed with custom instance you can narrow types better than a global configured instance.

[Luffyyy]

In my use case the API is not in the same domain (Laravel API localhost:8000) so baseURL is relevant and copy pasting it around isn't great.

For typing I mean more for arguments, nuxt uses a lot of generics, I might be wrong and these are automated in some ways, kinda new to typescript.

Guess I didn't think about other modules using it that's a good point. Now I'm leaning toward the pull you made with custom instances.

[danielroe]

A different baseURL is an example of why setting these properties on the default $fetch would cause problems. Nitro uses $fetch itself to perform fetches 'within' the server, and if the base URL were overridden, these would break unexpectedly.

... but I think it should be possible to address your root issues, if we can define them clearly enough.