$fetch not working with the new shared folder properly
I have a composable in my shared folder that uses $fetch to query nitro endpoints. However for some reason it says
"/api/v1/data/agents": <no response> Failed to parse URL from /api/v1/data/agents
8 Replies
Hi @Just Simeon. 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 provided in the knowledge sources, it appears that you're encountering an issue with
$fetch
in a composable within your shared folder. This error suggests there might be a problem with how the URL is being parsed or constructed. Let's explore a few potential causes and solutions:
1. URL Construction: Make sure you're constructing the URL correctly. If you're using a relative path, ensure it's properly formatted. The error message indicates that the URL "/api/v1/data/agents" is not being parsed correctly.
2. Base URL Configuration: If you're using a base URL, make sure it's properly configured. According to the GitHub issue #29626 (https://github.com/nuxt/nuxt/issues/29626), overriding the default $fetch
handler can cause issues. Instead of overriding it, you should create your own fetch with a different name.
3. Server Proxy: If you're using a proxy, ensure it's correctly set up. As mentioned in a GitHub issue comment (https://github.com/nuxt/nuxt/issues/29575), using a server proxy can help resolve similar issues:
4. API Routes: Ensure that your API routes are correctly set up. According to the Nitro documentation (https://nitro.unjs.io/deploy/providers/vercel#api-routes), if you're using Vercel, you should use server/api/
for Nuxt projects instead of the /api
directory.
5. Direct API Calls: Remember that $fetch
handles direct API calls differently on the server and client side. As mentioned in the Nuxt documentation (https://nuxt.com/docs/guide/concepts/server-engine#direct-api-calls), it will make direct API calls if running on the server, or client-side calls if running on the client.
If these suggestions don't resolve your issue, you might want to double-check your Nuxt configuration, especially regarding API routes and server middleware. Also, ensure that you're using useAsyncData
or useFetch
when appropriate to prevent issues with SSR, as explained in the Nuxt documentation on data fetching (https://nuxt.com/docs/getting-started/data-fetching#suspense).
If the problem persists, you may need to provide more details about your specific setup and code for a more targeted solution.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------<@294593079812292609> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
@kapa.ai my api routes work fine, however I can't call them from the shared folder
Let me check the knowledge base for you again. One moment! :books:
----------------------
Based on the information provided in the knowledge sources and your specific situation, it seems you're encountering an issue with calling API routes from the shared folder in a Nuxt application. This is likely related to how Nuxt handles composables and API calls outside of the Vue component lifecycle. Let's explore why this might be happening and how to address it:
1. Composable Context: Nuxt composables, including those that use
$fetch
or useFetch
, are designed to be used within specific contexts, such as Vue setup functions, Nuxt plugins, or route middleware. As explained in the Nuxt documentation on auto-imports (https://nuxt.com/docs/guide/concepts/auto-imports#vue-and-nuxt-composables), using these outside of the proper context can lead to errors.
2. Synchronous Execution: The documentation states that composables must be used synchronously within the correct context. Using them in standalone files or asynchronous functions can cause issues.
3. Alternative Approach: To resolve this, you have a few options:
a. Use $fetch
directly: Instead of using Nuxt-specific composables in your shared folder, you can use $fetch
directly. This is demonstrated in a solution provided in a Stack Overflow answer (https://stackoverflow.com/questions/78680613):
b. Move the API call logic: If possible, consider moving the API call logic to a component or a Nuxt plugin where you can safely use Nuxt composables.
c. Use a regular function: Instead of a composable, use a regular function in your shared folder that can be imported and used within components or other appropriate contexts.
4. Server vs. Client: Remember that $fetch
behaves differently on the server and client sides. On the server, it makes direct API calls, while on the client, it makes client-side calls. Ensure your shared code accounts for this difference if necessary.
5. Runtime Config: If you need to access runtime config or other Nuxt-specific features, you might need to restructure your code to use these within the proper Nuxt lifecycle hooks or components.
By adapting your shared folder code to use $fetch
directly or restructuring your API calls to occur within the proper Nuxt contexts, you should be able to resolve the issue of calling API routes from the shared folder.
Nuxt Auto-imports Documentation (https://nuxt.com/docs/guide/concepts/auto-imports#vue-and-nuxt-composables)
Stack Overflow Solution (https://stackoverflow.com/questions/78680613)
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------<@294593079812292609> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
Why do you have a composable in your shared folder? As i understand it, it should be for non-nuxt related code, etc validation schemas, or types shared between Nuxt and nitro, etc.
If you want want to mimic this behaviour, I think it's better to make a Nuxt layer (call it common?) and put your composables there. And every app that requires it can extend this layer.
And if you wanted this composable to be shared between the frontend and server, then putting it in the composables should be fine, right?
yes and no, the composable calls a mitt event system I have to emit different events.
the composable (which actually should just be a nitro plugin) is just a scraper that continuously calls 2 api endpoints.
However it also performs several checks, one of which can trigger an alert that I also want to receive in the frontend
sorry, i don't fully understand the big picture to help you
can you try rephrasing it again?