useAsyncData returning data nested in _rawValue

[gregg-cbs]

In all the docs iv read about useAsyncData and useFetch ... none of them talk about this strange object structure I am getting.

I am confused why in the docs it makes the return from the above to methods seem flat but when using it, it is nesting the data inside _rawValue, any ideas?:

My request:

//
const { data, error } = await useAsyncData('orders', () => $fetch('/api/orders'), {
  server: true
})

// i also tried axios
const {data, pending, error} = await useAsyncData('orders', async () => await axios('/api/orders'), {
  server: false
});

either way i get:

{
  "data": {
    "_shallow": false,
    "__v_isRef": true,
    "_rawValue": {
      "orders": [],
      "statistics": {}
    }
  },
  "pending": {
    "_shallow": false,
    "__v_isRef": true,
    "_rawValue": false,
    "_value": false
  },
  "error": {
    "_shallow": false,
    "__v_isRef": true,
    "_rawValue": null,
    "_value": null
  }
}

[hagemann]

https://github.com/nuxt/framework/discussions/2189#discussioncomment-1715049

[NathanD19]

Hey @gregg-cbs, did you end up solving this? I'm running into the same issue.

Requests returning _rawValue:

Should be:

{ content: {...} }

[gregg-cbs]

@NathanD19 - Yeah I moved to NextJS, and their new version with the app folder is going to be next level. I highly recommend moving over. Specifically I am using the T3 Stack.

[gregg-cbs]

And to add to my comment. I was a huge fan of Vue, i chose it over React every time and I moved a lot of companies onto Vue2. But the new Nuxt and Vue 3 frustrates me so much - I dont understand some of their design choices. I find React and Nextjs are fixing the irritating things about React and progressing these kind of frameworks forward in a way that no other framework can come close to.

As an engineer who wants to build next level projects and have coding flexibility to meet my project requirements I can say that Nextjs and its stacks do this for me.

See stacks like Remix and T3 mentioned above. Super cool.

[larryh]

I'm having the same problem with useFetch()

Maybe the authors see it as a "feature", but I sure don't. Especially when none of the docs I have looked at - and I've been screwing around with this for hours - mentions what is really returned. They all just show simple destructuring, e.g.

const { data } = await useFetch(request, { options }) or const { data: user } = await useFetch(request, { options })

If you try to do something with that data - like store it in Pinia or Nuxt's 'useState' you're screwed. Instead you have to remember to work with

data._rawValue

all over the place - which just really smells. (imo)

[NathanD19]

Would great to get an official response on this one as to why this is the case. Or the very least, the recommended way to work around this.

[larryh]

I agree. To me it doesn't make sense. We have our code make a request to the server. We take great pains to make sure the back-end gives us the JSON that we want and expect. Opening up the browser's Dev Panel we can see in the "Network" tab that the back-end is returning exactly what we want.

And then when we access the 'data' that most, if not all, of the code examples show on the web we get... a bunch of crap added to our response.

Sorry for the tone. I do appreciate all of the work people do on this. But why on earth don't you just give us what we ask for and expect?!

[mozart25]

ya, same issues. How to handle?

[TheAlexLichter]

Everbody asking about that "weird structure" should read the docs about Vue's composition API, Reactivity in Vue 3 and refs ☺️

[larryh]

I did. And what you are pointing people to is entirely different from what these conversations (i.e. complaints) have been about.

If you submit a request to a server, be it from a Vue, React, Angular, Ember, jQuery, or whatever app, and that server returns some JSON that the developers have decided they wanted... then that is what they should get. Period. It has nothing to do with the client-side framework's internals.

And speaking of docs - what made this issue worse was that none of the docs discussed and/or illustrated what was actually happening. And I'm talking about docs having to do with fetch-related things, i.e. where one would turn to when fetching data, not reactivity and ref implementations.

[TheAlexLichter]

If you submit a request to a server, be it from a Vue, React, Angular, Ember, jQuery, or whatever app, and that server returns some JSON that the developers have decided they wanted... then that is what they should get. Period.

Yes, if you use e.g. the fetch API, something like axios, or $fetch, absolutely. We don't patch any internal functions or similar, so this still works fine.

It has nothing to do with the client-side framework's internals.

Here I have a different opinion. If you use above mentioned functions/fetching libraries and need SSR, then you have the issue that the content won't be part of the HTML or the request will be repeated on the server and client-side (as documented). Hence, you want to use the frameworks fetching composable, returning a ref.

And speaking of docs - what made this issue worse was that none of the docs discussed and/or illustrated what was actually happening. And I'm talking about docs having to do with fetch-related things, i.e. where one would turn to when fetching data, not reactivity and ref implementations.

I agree. We have the data fetching guide, but nowhere it is mentioned that data, pending and error are refs. Here, a PR is welcome - I'll create an issue right away!