PayloadExtraction/useFetch persists data when it shouldn't

[madsh93]

Environment

---

• Operating System: Linux
• Node Version: v16.20.0
• Nuxt Version: 3.6.5
• Nitro Version: 2.5.2
• Package Manager: yarn@1.22.19
• Builder: vite
• User Config: devtools, experimental, nitro
• Runtime Modules: -
• Build Modules: -

---

Reproduction

https://stackblitz.com/edit/github-4ym9i1?file=pages%2F%5Bid%5D%2Findex.vue

Describe the bug

To reproduce:

1. yarn run build
2. node .output/server/index.mjs
3. Go to a product and select a size
4. Go back
5. Go to same product as in step 3

You'll then see the size is not the default size.

Additional context

No response

Logs

No response

[stackblitz]

Start a new pull request in StackBlitz Codeflow.

• github-4ym9i1 (Open reproduction)

[danielroe]

You should use route.fullPath as the key rather than route.path if query params are significant to the return value of the asyncData fetcher.

[madsh93]

Not sure how to reopen this. The issue is not fixed by setting route.fullPath or removing the key entirely.

[94726]

This isn't exactly related to #22277, but they do share some problems.

Setting a specific key doesn't really help in this situation, as it's usually going to have the same value. Because routing using query-params doesn't change the component instance, the asyncData key won't update unless actually switching the route. Also when going back and clicking on the same product, there are again no query-params so it's the same key.

---

But to explain why this is only happening when using payloadExtraction, I broke down what happens at each step of your reproduction:

3. Go to a product
   3.1. select a size
   This will trigger the watch and fetch a new product with that size. (always skips getCachedData() because of _initial isn't true
   The result of that fetch updates asyncDatas data
4. Go back
5. Go to same product as in step 3
   _initial is true
   hasCachedData() is true (payload extracted data in nuxt.static.data[key]
   Therefore we skip fetching new data because of
   

   nuxt/packages/nuxt/src/app/composables/asyncData.ts

   Lines 168 to 170 in a682194

   	if ((opts._initial || (nuxt.isHydrating && opts._initial !== false)) && hasCachedData()) {
   	return getCachedData()
   	}

   
   But because we skipped creating a new promise, the previous asyncDataPromise is returned, which still has the old data.
   

   nuxt/packages/nuxt/src/app/composables/asyncData.ts

   Lines 276 to 279 in a682194

   	const asyncDataPromise = Promise.resolve(nuxt._asyncDataPromises[key]).then(() => asyncData) as AsyncData<ResT, DataE>
   	Object.assign(asyncDataPromise, asyncData)
   	return asyncDataPromise as AsyncData<PickFrom<DataT, PickKeys>, DataE>

The getCachedData() would actually have the correct value, but the return statement doesn't control the data value of asyncData. Instead, something like the following would be necessary.

 if ((opts._initial || (nuxt.isHydrating && opts._initial !== false)) && hasCachedData()) {
+  asyncData.data.value = getCachedData()
   return getCachedData() 
 } 

[Gruce]

Have the exact same problem.

[madsh93]

Thank you for your analysis @94726 hopefully this can get resolved. I haven't met many who has run into this issue, which makes me think I'm following bad practice. Do you have any idea if this is in fact so? From my point of view this is a basic way of fetching.

[94726]

@madsh93 to me, the general usecase in your reproduction seems very resonable. I can see myself and others trying something similar when working with paginated queries, for example.

But now that I think about it, while this issue is likely a bug, it might be highlighting a missing feature too.
This problem could also be solved by allowing dynamic keys like this:

useAsyncData(() => route.fullPath, () => $fetch(...))

Most usecases of the watch option would probably benefit from using the watched values as (additional) keys.

[Sandros94]

@madsh93 to me, the general usecase in your reproduction seems very resonable. I can see myself and others trying something similar when working with paginated queries, for example.

But now that I think about it, while this issue is likely a bug, it might be highlighting a missing feature too. This problem could also be solved by allowing dynamic keys like this:

useAsyncData(() => route.fullPath, () => $fetch(...))

Most usecases of the watch option would probably benefit from using the watched values as (additional) keys.

Something that I had in mind when opening #23000

[madsh93]

Can confirm this still does not work in 3.8.1

[manniL]

Interesting issue. I've used

const { data: product } = await useFetch('/api/product', {
  key: route.fullPath,
  params
})

And locally it works (with build) - but not in stackblitz 🙈
Can you check if that's the case for you too?

weird-behavior-usefetch-payload.webm

[madsh93]

Hey @manniL

Thanks for taking a look. Interesting that it works for you locally on build. In my case it doesn't. I've used your example with useFetch and still on nuxt 3.6.5 (also tested with 3.8.2 with same result) as in the repo I provided. I'm on node v18.17.1