Nuxt 4 - useFetch breaks when using the "default" option
I have a component that calls useFetch.
This component is only rendered on the client. I boot this component up twice with different endpoints. When the default parameter is specified no network call is made. I've ensured that the key is unique for each component. If I remove the default parameter things work fine. I feel like this is a bug.
3 Replies
Hi @Byte. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Based on the information in the knowledge sources, the behavior you're experiencing with the useFetch composable and the default option is not described as a bug, but rather as expected behavior under certain conditions.
Here's what the documentation and related issues clarify:
- The default option in useFetch provides a factory function to set the default value of data before the async function resolves. This is especially useful with lazy: true or immediate: false, where you want to show a placeholder value before the actual data is fetched [useFetch Parameters].
- If you set server: false (client-only fetching), the data will not be fetched until hydration completes, and even if you await useFetch on the client side, data will remain null within <script setup> until the fetch actually happens [useFetch Return Values].
- The getCachedData option (which defaults to checking Nuxt's payload or static data) only caches data when experimental.payloadExtraction is enabled. If your data is being cached and not refetched, it could be related to this mechanism [useFetch Parameters].
- When using the same key for multiple useFetch calls, they will share the same data, error, and status refs. However, you mentioned that your keys are unique, so this should not be the cause [Minimize payload size].
There is no explicit mention in the documentation or issues that providing a default option should prevent a network call from being made. The default is only meant to provide an initial value until the fetch resolves. If removing default causes the fetch to work as expected, but adding it prevents the network call, this is not documented as intended behavior.
Possible causes to investigate:
- Ensure that immediate is not set to false, as this would prevent the fetch from firing automatically.
- Check if lazy is set to true, which would delay the fetch until after navigation.
- Make sure that the getCachedData function is not returning a value that would prevent the fetch (by default, it only caches if experimental.payloadExtraction is enabled).
- Double-check that your keys are truly unique and not colliding.
Summary:
The knowledge sources do not explicitly mention that providing a default option to useFetch should prevent a network call. The default is only for initial data before the fetch resolves. If you are seeing no network call at all, and removing default fixes it, this may be an unintended side effect or a bug, but it is not documented as such. You may want to create a minimal reproduction and open an issue with the Nuxt team if this behavior persists. References:
- useFetch Parameters - useFetch Return Values - Minimize payload size ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
The knowledge sources do not explicitly mention that providing a default option to useFetch should prevent a network call. The default is only for initial data before the fetch resolves. If you are seeing no network call at all, and removing default fixes it, this may be an unintended side effect or a bug, but it is not documented as such. You may want to create a minimal reproduction and open an issue with the Nuxt team if this behavior persists. References:
- useFetch Parameters - useFetch Return Values - Minimize payload size ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
<@224924542340956160> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
Stupidly enough setting server: false resolves the issue. Bad fix imo