fix(nuxt): recreate asyncData when immediate is disabled

[jongmin4943]

🔗 Linked issue

#20979

❓ Type of change

• 📖 Documentation (updates to the documentation, readme or JSdoc annotations)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

Resolves #20979

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[jongmin4943]

How do I write a test for this?

[danielroe]

If multiple invocations of useAsyncData are used (for example, in components) and one is unmounted, this would unset data for the others. It will also lead to the wrong behaviour when we're using payload extraction (for example, on a statically generated site it will remove data from the payload).

How about, instead, re-initialising the value using options.default when useAsyncData is called with immediate: false? (We'll still need to think about whether this is desired behaviour.)

[jongmin4943]

If multiple invocations of useAsyncData are used (for example, in components) and one is unmounted, this would unset data for the others. It will also lead to the wrong behaviour when we're using payload extraction (for example, on a statically generated site it will remove data from the payload).

How about, instead, re-initialising the value using options.default when useAsyncData is called with immediate: false? (We'll still need to think about whether this is desired behaviour.)

I also thought about using options.default first actually. I'll try that. Thanks for the quick reply.

[jongmin4943]

@danielroe I was considering where to put the re-installation codes carefully. Could you check that this is okay? Thanks!

done

[nuxt-studio]

✅ Live Preview ready!

Name	Edit	Preview	Latest Commit
Nuxt Docs	Edit on Studio ↗︎	View Live Preview	a601ae6

[danielroe]

I'm not sure about the approach here, as if the state is shared with another composable it will clear it out.

What about instead updating L124 to:

if (!nuxt._asyncData[key] || !options.immediate) {

That way it would give a 'clean slate' for each new call of the composable but not interfere with other composable calls.

Maybe it would be valuable to add a test to the suite to cover these edge cases, as well as the original issue. Would you be able to add a test as part of the PR?

[jongmin4943]

I tried adding some more conditions at L124 before. If !options.immediate added, other components that have useAsyncData with the same key will not use cached data. It always makes new value. Even though they have the same key, they do not hold equal value.

That way it would give a 'clean slate' for each new call of the composable but not interfere with other composable calls.

If I understand correctly, it means options.immediate : false will always create new value although the same key is provided?

BTW, I am not familiar with writing a test. Could you please give me some advice for a test if possible?

[danielroe]

I think at the moment the best way to write a test for this is to do an e2e test in test/basic.test.ts. You will probably need to create some pages in test/fixtures/basic/pages and test/fixtures/basic/components. You'll use createPage to go to a page with some data, then navigate to another page. And you can make some assertions about what should happen.

I would make sure to test that data isn't removed from a component that persists (e.g. in a layout) but that 'old' data doesn't persist when re-initialising useAsyncData in the new page. And confirm that the test fails on main branch but passes in this one.

[jongmin4943]

@danielroe I'm sorry for the late response. I was completely lost because I had a hard time writing a test haha.. I'm not sure this is the right approach. Could you please review?

[danielroe]

Thank you ❤️