kāné
Nuxt 3 API Endpoint Data Lost During Server-Client Transfer Despite Valid Server-Side Data
I'm experiencing a puzzling issue with my Nuxt 3 application where data is being lost during the transfer from server to client, despite the data being valid on the server side.
Setup
I have a view model that handles data transformation:
And an API endpoint that returns this data:
On the client side, I'm fetching the data:
The Weird Part
* The server-side logs show the data is valid and structured correctly
* If I explicitly return a plain object with the same properties within the API endpoint, instead of
return item.toJSON()
it works:
* Returning item.toJSON() results in a null
response on the client side
* I've tried various serialization approaches (superjson, JSON.stringify/parse) but the issue persists
What's going on here? Why does explicitly creating a new object work while returning the toJSON() result doesn't? Is there something about Nuxt's serialization that I'm missing?5 replies
Restarted dev server, 503 error: ENOENT: no such file or directory worker-56658-1.sock
I decided to restart my dev server, and now it's returning 503 errors of all of a sudden.
I get this showing up as the page title when I try access
localhost:3000
I tried clearing out all the usual cache suspects.
rm -rf .nuxt .output .node_modules
Reinstalling everything
pnpm install
Rebuilding
pnpm run build
And then firing up the server again
pnpm dev
And the error is still happening.
This is the second time it's happened in one day. The first time, I found this github issue: https://github.com/nuxt/nuxt/issues/24170
One person suggested restarting the computer. I did that, but it didn't fix it.
Feels like erratic behavior so I'm not sure where to even look.
I just upgraded my node to v23.5.0 and nuxt to 3.15.0 to see if that would help with anything, but it didn't.
If it helps, my app is within a monorepo using a pnpm workspace. I am reference another package within the monorepo as a dependency for my nuxt app. I don't think its related as things were working for sometime...28 replies
Issue with Vue 3 + Nuxt 3 useFetch Data Not Displaying in Template
Background
I’m building an app using Nuxt 3 and Vue 3 (Node v20.18.0). I’m running into a fundamental issue with template reactivity when trying to display data fetched with
useFetch
. Specifically:
- I can log the data from useFetch
in <script setup>
, and the data is correct.
- However, when binding to the fetched data in the template, the expected reactivity doesn’t occur.
- Some solutions work (like wrapping the data in computed
), but they feel unnecessary for something as fundamental as this.
What I’ve Tried
1. Debugging Data Reactivity
- These logs always show the correct data and title values.
2. Providing Default Values
- Ensures data.value
is initialized, but this doesn’t fix the template reactivity for data.value.title
.
3. Optional Chaining in the Template
- Prevents errors but still doesn’t display the title, even though <pre>{{ data }}</pre>
confirms it exists.
4. Using computed
- This works, and the title renders correctly when accessed as computedData.title
.
Questions
1. Why is template reactivity for data.value.title
failing?
- This seems like a fundamental part of Vue’s reactivity system, so I’m not sure why I need computed
for it to work.
2. Is this an issue with Nuxt’s useFetch
?
- Could Nuxt be optimizing reactivity in a way that breaks expected behavior for deep properties?
3. Am I misusing useFetch
?
- Is there a better way to fetch data in Nuxt 3 to avoid this issue entirely?
4. Is this a known issue?
- I couldn’t find documentation addressing this specific behavior. Should I file a bug report?6 replies
Nuxt Dynamic Route Issue: ID Switching to 'preload.js.map' Unexpectedly
I have a very simple dynamic route. The page is in the following directory:
~/pages/explore/initiative/[id].vue
When I navigate to that page via NuxtLink, it seems to be making the request several times.
I added the following code to [id].vue
to verify if this is the case
Here's an example of the output
So it seems that the ID is being switched to preload.js.map
. I didn't write any code to that switch, so it seems to be the framework making the request or some other package included within.
Not sure if this is relevant, but there's also an index.vue
page in ~/pages/explore/initiative/index.vue
6 replies