Nuxt•2mo ago

custom useFetch composable return typing response

This is my useCustomFetch wrapper.

import type { UseFetchOptions } from 'nuxt/app'

export function useCustomFetch<T>(
  url: Parameters<typeof $fetch>[0],
  options: UseFetchOptions<T> = {},
) {
  return useLazyFetch(url, {
    credentials: 'include',
    ...options,
    onResponseError(context) {
      if (context.response.status === 401) {
        navigateTo('/login')
      }
    },
  })
}

import type { UseFetchOptions } from 'nuxt/app'

export function useCustomFetch<T>(
  url: Parameters<typeof $fetch>[0],
  options: UseFetchOptions<T> = {},
) {
  return useLazyFetch(url, {
    credentials: 'include',
    ...options,
    onResponseError(context) {
      if (context.response.status === 401) {
        navigateTo('/login')
      }
    },
  })
}

in server/api/public/test.get.ts I created a simple json response.

export default defineEventHandler(event => {
  return {
    a: 'a',
    b: 'b',
    nested: {
      c: 'c',
      d: 'd',
    },
  }
})

export default defineEventHandler(event => {
  return {
    a: 'a',
    b: 'b',
    nested: {
      c: 'c',
      d: 'd',
    },
  }
})

If I use normal useFetch it already knows the response from the endpoint and it apply types and in majority of cases (atleast in theory) I won't even need to write types for the reponses

9 Replies

kapa.ai•2mo ago

Hi @Tilko. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- You're correct that when you use Nuxt's built-in useFetch, it can often infer the response type from your server API routes, especially if you use TypeScript and your endpoints are colocated in server/api. This type inference is a feature of Nuxt's auto-generated types for server routes, which works seamlessly with useFetch. However, when you create a custom wrapper like useCustomFetch, you may lose this automatic type inference unless your wrapper's signature and usage closely match the original useFetch composable. The Nuxt documentation and community discussions highlight this limitation: - If you wrap useFetch in a custom composable and change its signature (for example, by making it async or altering the return type), you may lose the enhanced type inference and reactivity that useFetch provides out of the box. This is because the type inference relies on the direct usage of useFetch and its expected generics and parameters. If you return the result of useFetch directly (without awaiting or altering it), you can preserve most of the type inference and reactivity features Custom useFetch in Nuxt. - The Nuxt team recommends returning useFetch directly from your custom composable, as in:

  import type { UseFetchOptions } from 'nuxt/app'

  export function useAPI<T>(
    url: string | (() => string),
    options?: UseFetchOptions<T>,
  ) {
    return useFetch(url, {
      ...options,
      $fetch: useNuxtApp().$api as typeof $fetch
    })
  }

  import type { UseFetchOptions } from 'nuxt/app'

  export function useAPI<T>(
    url: string | (() => string),
    options?: UseFetchOptions<T>,
  ) {
    return useFetch(url, {
      ...options,
      $fetch: useNuxtApp().$api as typeof $fetch
    })
  }

This approach preserves the type inference for the response, so you get the same experience as with useFetch Custom useFetch in Nuxt. - If you use useLazyFetch instead of useFetch, the same principle applies: as long as you return the result directly and don't change the function's signature, you should retain type inference. - If you want to further customize the error type, you can do so by specifying the error generic parameter, as shown in the docs. Summary:
To preserve automatic response typing in your custom useFetch (or useLazyFetch) wrapper, ensure your composable returns the result of useFetch/useLazyFetch directly and does not alter its signature or return type. If you do this, Nuxt's type inference for API responses should continue to work as expected Custom useFetch in Nuxt. If you notice that type inference is not working, double-check that your wrapper's signature matches the original composable and that you are not awaiting or otherwise altering the return value before returning it. If you need to support default values or more advanced typing, see the discussion about customizing the options type to match useFetch's behavior docs: fix options type in custom useFetch recipe. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

kapa.ai•2mo ago

<@254138818351988737> Kapa.ai is still learning and improving, please let me know how I did by reacting below.

TilkoOP•2mo ago

manage to create it like this

export const useCustomFetch: typeof useLazyFetch = (url, options = {}) => {
  return useLazyFetch(url, {
    credentials: 'include',
    ...options,
    onResponseError(context) {
      if (context.response.status === 401) {
        navigateTo('/login')
      }
    },
  })
}

export const useCustomFetch: typeof useLazyFetch = (url, options = {}) => {
  return useLazyFetch(url, {
    credentials: 'include',
    ...options,
    onResponseError(context) {
      if (context.response.status === 401) {
        navigateTo('/login')
      }
    },
  })
}

it automatically detects also all the endpoints for autocomplete and basically is the same as regular useFetch. work flawlessly

flapili•2mo ago

Hi, take a look at $fetch.create Then you could pass the fresh $fetch instance to useFetch, if you need it, and if you only need to do a request without usefetch you can still use it

TilkoOP•2mo ago

for now I don't really see a big benefit for that so I'm just having a compoasable... maybe I need to do now a few tricks if I wanna have also custom onResponseError in the because this default one overrides it. In theory I wanna use only useCustomFetch for all the requests and occasionally just pass server:false to it. I really like that I don't have to manually use typing for every api response. prisma orm is quite powerful for that. but thanks for the reply. If I will see the need for it I will create a plugin with fetch.create

flapili•2mo ago

https://youtu.be/b1S5os65Urs?si=WP1O4Q05DxEoanMA

LearnVue

YouTube

You're Probably Using Nuxt Wrong

RESOURCES Source Code - https://github.com/nuxt/nuxt/blob/fdbfed1280839171b160f388f1977fb08d89a23d/packages/nuxt/src/app/composables/asyncData.ts#L198 ✅ Join the LearnVue+ Waiting List - https://learnvue.co Get early access to videos, exclusive content, interactive code challenges, and more. follow me on twitter https://twitter.com/mattma...

TilkoOP•2mo ago

yeah I watched this many times XD but he doesn't really use any useFetch wrappers for authentication or something else. I've looked also in docs but my approach for now works completely fine (considering I'm using nuxt also for BE). Probably for bigger / enterprise projects I would choose more structured/complex approach

TilkoOP•2mo ago

for now I wanted to achieve that without any custom types/interfaces I already get autocomplete and type checking

flapili•2mo ago

You can just use $fetch.create It will get autocomplete too

Gaming

Programming

custom useFetch composable return typing response

Did you find this page helpful?