fix(nuxt)!: don't rerun asyncdata w/ existing data in useAsyncData
#32170
Conversation
|
|
@nuxt/kit
nuxt
@nuxt/schema
@nuxt/rspack-builder
@nuxt/vite-builder
@nuxt/webpack-builder
commit: |
CodSpeed Performance ReportMerging #32170 will not alter performanceComparing Summary
|
a216c72 to
762a7f8
Compare
useAsyncDatauseAsyncData
There was a problem hiding this comment.
Pull Request Overview
This PR fixes redundant re-execution of asyncData when calling useAsyncData with an existing successful result.
- Adjusts test expectations to reflect fewer asyncData handler calls.
- Adds a condition to avoid triggering initialFetch if the asyncData call has already succeeded.
- Improves the unregister logic in the key watcher by ensuring cleanup only occurs for changed keys.
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| test/nuxt/composables.test.ts | Updated test assertions to reflect the new behavior (fewer calls). |
| packages/nuxt/src/app/composables/asyncData.ts | Added a status check in the immediate branch and refined key cleanup. |
Comments suppressed due to low confidence (3)
test/nuxt/composables.test.ts:533
- The updated expected call count reflects the fix for redundant fetching. Ensure that the test scenarios adequately cover cases with multiple components accessing the same asyncData key.
expect(promiseFn).toHaveBeenCalledTimes(1)
packages/nuxt/src/app/composables/asyncData.ts:309
- This added status check prevents re-fetching when asyncData has already succeeded. Please verify that this condition covers all intended scenarios, such as when error states occur but valid data exists.
} else if (options.immediate && asyncData.status.value !== 'success') {
packages/nuxt/src/app/composables/asyncData.ts:337
- The change to unregister only when the key actually changes helps avoid premature cleanup. Confirm that all edge cases where the key remains unchanged are safely handled.
if (oldKey && oldKey !== newKey) {
WalkthroughThe changes update the internal logic of the 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (2)
⏰ Context from checks skipped due to timeout of 90000ms (4)
🔇 Additional comments (7)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
🔗 Linked issue
resolves #32165
📚 Description
this prevents rerunning the handler when calling
useAsyncData('key')if anotheruseAsyncData('key')is already instantiated and not cleaned up...this likely needs a careful review (cc: @TheAlexLichter) to make sure we don't introduce a regression in behaviour - note that this requires updating the unit tests because handlers now run less frequently when a second component is loaded and another one is still in memory.