-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
docs: add signal support to useAsyncData examples #33601
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
|
|
Warning Rate limit exceeded@OrbisK has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 4 minutes and 1 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
WalkthroughThis pull request updates Nuxt documentation examples to thread an AbortSignal through useAsyncData handlers. Handler signatures are changed to accept a second parameter ({ signal }) — e.g. async (_nuxtApp, { signal }) => … — and all internal $fetch calls are updated to pass that signal (e.g. $fetch('/path', { signal })). The API reference adds a public AsyncDataHandler type alias describing the handler signature and updates useAsyncData overloads to use it. Changes appear across getting-started, guide, and multiple API composable docs. Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
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. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docs/3.api/2.composables/use-async-data.md(6 hunks)
🧰 Additional context used
🪛 LanguageTool
docs/3.api/2.composables/use-async-data.md
[uncategorized] ~131-~131: Loose punctuation mark.
Context: ...options.timeout duration is exceeded ::warning [useAsyncData](/docs/4.x/api/...
(UNLIKELY_OPENING_PUNCTUATION)
🪛 markdownlint-cli2 (0.18.1)
docs/3.api/2.composables/use-async-data.md
90-90: Trailing spaces
Expected: 0 or 2; Actual: 1
(MD009, no-trailing-spaces)
🔇 Additional comments (5)
docs/3.api/2.composables/use-async-data.md (5)
23-26: Signal parameter correctly introduced in first example.The usage example clearly demonstrates passing the signal to the
$fetchcall, setting a good precedent for subsequent examples.
46-56: Watch Params example correctly uses signal.The example properly demonstrates signal usage alongside other
$fetchoptions likeparams. The placement within the options object is correct.
197-203: Shared State examples correctly updated with signal support.The examples consistently apply the signal parameter and maintain clarity about which option combinations are allowed. Well done.
232-242: Type alias refactoring improves documentation clarity.The introduction of
AsyncDataHandler<ResT>type alias reduces duplication and makes the type signature easier to understand. Both function overloads now consistently reference this alias, improving maintainability.
32-36: Spacing adjustment before "Watch Params" section.The blank line addition provides better visual separation between sections. This is appropriate for Markdown documentation structure.
| ### Make your `handler` abortable | ||
|
|
||
| You can make your `handler` function abortable by using the `signal` provided in the second argument. This is useful for cancelling requests when they are no longer needed, such as when a user navigates away from a page. `$fetch` natively supports abort signals. | ||
|
|
||
| ```ts | ||
| const { data, error } = await useAsyncData( | ||
| 'users', | ||
| (_, { signal }) => $fetch('/api/users', { signal }), | ||
| ) | ||
|
|
||
| refresh() // will actually cancel the $fetch request (if dedupe: cancel) | ||
| refresh() // will actually cancel the $fetch request (if dedupe: cancel) | ||
| refresh() | ||
|
|
||
| clear() // will cancel the latest pending handler | ||
| ``` | ||
|
|
||
| You can also pass an `AbortSignal` to the `refresh`/`execute` function to cancel individual the request manually. | ||
|
|
||
| ```ts | ||
| const { refresh } = await useAsyncData( | ||
| 'users', | ||
| (_, { signal }) => $fetch('/api/users', { signal }), | ||
| ) | ||
| const abortController = new AbortController() | ||
|
|
||
| function handleUserAction () { | ||
| refresh({ signal: abortController.signal }) | ||
| } | ||
|
|
||
| function handleCancel () { | ||
| abortController.abort() // aborts the ongoing refresh request | ||
| } | ||
| ``` | ||
|
|
||
| If your `handler` function does not support abort signals, you can implement your own abort logic using the `signal` provided. | ||
|
|
||
| ```ts | ||
| const { data, error } = await useAsyncData( | ||
| 'users', | ||
| (_, { signal }) => { | ||
| return new Promise((resolve, reject) => { | ||
| signal?.addEventListener('abort', () => { | ||
| reject(new Error('Request aborted')) | ||
| }) | ||
| return Promise.resolve(callback.call(this, yourHandler)).then(resolve, reject) | ||
| }) | ||
| }, | ||
| ) | ||
| ``` | ||
|
|
||
| The handler signal will be aborted when: | ||
|
|
||
| - A new request is made with `dedupe: 'cancel'` | ||
| - The `clear` function is called | ||
| - The `options.timeout` duration is exceeded | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
New abortable handler section is comprehensive, but has formatting issues.
The documentation section effectively explains abort signal support with practical examples. However, there are two formatting issues flagged by linters:
- Line 90 has a trailing space (should be removed)
- Line 131 has a formatting issue with the opening
::warningmarker (should be on its own line for proper Markdown rendering)
Apply this diff to fix the formatting:
refresh() // will actually cancel the $fetch request (if dedupe: cancel)
refresh() // will actually cancel the $fetch request (if dedupe: cancel)
refresh()
clear() // will cancel the latest pending handler
-```
+```
You can also pass an `AbortSignal` to the `refresh`/`execute` function to cancel individual the request manually.Also, verify that line 131 renders correctly. If the ::warning block does not render properly after line 130, move it to a new line:
- The `clear` function is called
- The `options.timeout` duration is exceeded
-
+
::warning📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ### Make your `handler` abortable | |
| You can make your `handler` function abortable by using the `signal` provided in the second argument. This is useful for cancelling requests when they are no longer needed, such as when a user navigates away from a page. `$fetch` natively supports abort signals. | |
| ```ts | |
| const { data, error } = await useAsyncData( | |
| 'users', | |
| (_, { signal }) => $fetch('/api/users', { signal }), | |
| ) | |
| refresh() // will actually cancel the $fetch request (if dedupe: cancel) | |
| refresh() // will actually cancel the $fetch request (if dedupe: cancel) | |
| refresh() | |
| clear() // will cancel the latest pending handler | |
| ``` | |
| You can also pass an `AbortSignal` to the `refresh`/`execute` function to cancel individual the request manually. | |
| ```ts | |
| const { refresh } = await useAsyncData( | |
| 'users', | |
| (_, { signal }) => $fetch('/api/users', { signal }), | |
| ) | |
| const abortController = new AbortController() | |
| function handleUserAction () { | |
| refresh({ signal: abortController.signal }) | |
| } | |
| function handleCancel () { | |
| abortController.abort() // aborts the ongoing refresh request | |
| } | |
| ``` | |
| If your `handler` function does not support abort signals, you can implement your own abort logic using the `signal` provided. | |
| ```ts | |
| const { data, error } = await useAsyncData( | |
| 'users', | |
| (_, { signal }) => { | |
| return new Promise((resolve, reject) => { | |
| signal?.addEventListener('abort', () => { | |
| reject(new Error('Request aborted')) | |
| }) | |
| return Promise.resolve(callback.call(this, yourHandler)).then(resolve, reject) | |
| }) | |
| }, | |
| ) | |
| ``` | |
| The handler signal will be aborted when: | |
| - A new request is made with `dedupe: 'cancel'` | |
| - The `clear` function is called | |
| - The `options.timeout` duration is exceeded | |
| ### Make your `handler` abortable | |
| You can make your `handler` function abortable by using the `signal` provided in the second argument. This is useful for cancelling requests when they are no longer needed, such as when a user navigates away from a page. `$fetch` natively supports abort signals. | |
🧰 Tools
🪛 LanguageTool
[uncategorized] ~131-~131: Loose punctuation mark.
Context: ...options.timeout duration is exceeded ::warning [useAsyncData](/docs/4.x/api/...
(UNLIKELY_OPENING_PUNCTUATION)
🪛 markdownlint-cli2 (0.18.1)
90-90: Trailing spaces
Expected: 0 or 2; Actual: 1
(MD009, no-trailing-spaces)
🤖 Prompt for AI Agents
In docs/3.api/2.composables/use-async-data.md around lines 75–131, remove the
trailing space on line 90, wrap the "You can also pass an `AbortSignal`..."
paragraph with a standalone opening and closing triple-backtick fence (add ```
on its own line before and after that paragraph as suggested), and ensure the
`::warning` opening marker at or after line 131 is on its own line (move it to a
new line if currently appended) so the block renders correctly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
docs/3.api/2.composables/use-async-data.md (1)
74-123: New abort signal section is comprehensive but has minor text quality issue.The new "Make your handler abortable" section effectively explains abort signal support with three well-structured examples progressing from basic to advanced scenarios. However, line 91 contains a grammatical error.
Update line 91 to fix the grammatical error:
-You can also pass an `AbortSignal` to the `refresh`/`execute` function to cancel individual the request manually. +You can also pass an `AbortSignal` to the `refresh`/`execute` function to cancel the request individually.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docs/3.api/2.composables/use-async-data.md(5 hunks)
🧰 Additional context used
🪛 LanguageTool
docs/3.api/2.composables/use-async-data.md
[uncategorized] ~130-~130: Loose punctuation mark.
Context: ...options.timeout duration is exceeded ::warning [useAsyncData](/docs/4.x/api/...
(UNLIKELY_OPENING_PUNCTUATION)
🔇 Additional comments (5)
docs/3.api/2.composables/use-async-data.md (5)
19-26: Leading example correctly demonstrates signal support.The introductory usage example properly showcases the new
(_, { signal })handler pattern and passes it to$fetch. This sets expectations well for readers.
40-55: Watch params example correctly threads signal through.The signal is properly destructured and forwarded to
$fetchalongside the request parameters. Implementation is consistent with the introductory example.
125-131: Verify spacing between abort conditions list and warning block.The static analysis tool still flags line 130 for a loose punctuation mark issue related to the
::warningmarker. Ensure there is proper blank line separation between the bulleted list (ending at line 129) and the warning block.The current structure shows:
- The `options.timeout` duration is exceeded ::warningThis should render correctly, but please verify the Markdown rendering. If the warning block does not display properly, ensure it has a blank line before it and is not appended to the previous content.
228-241: Type signature changes properly document abort signal support.The introduction of the
AsyncDataHandler<ResT>type alias cleanly abstracts the handler signature, making it clear that handlers receive anAbortSignalvia theoptionsparameter. Both function overloads are correctly updated to use this type, improving API clarity and maintainability.
194-202: Shared state examples correctly updated with abort signal pattern.Both the ❌ (incorrect) and ✅ (correct) examples consistently demonstrate the
(_, { signal })handler pattern. This maintains clarity and guides developers toward proper usage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 3
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
docs/1.getting-started/10.data-fetching.md(4 hunks)docs/2.guide/3.going-further/1.experimental-features.md(1 hunks)docs/3.api/2.composables/use-async-data.md(5 hunks)docs/3.api/2.composables/use-nuxt-app.md(1 hunks)docs/3.api/2.composables/use-nuxt-data.md(1 hunks)docs/3.api/2.composables/use-request-fetch.md(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (5)
- docs/3.api/2.composables/use-nuxt-app.md
- docs/2.guide/3.going-further/1.experimental-features.md
- docs/1.getting-started/10.data-fetching.md
- docs/3.api/2.composables/use-request-fetch.md
- docs/3.api/2.composables/use-nuxt-data.md
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-09-10T14:42:56.647Z
Learnt from: Tofandel
PR: nuxt/nuxt#33192
File: test/nuxt/use-async-data.test.ts:366-373
Timestamp: 2025-09-10T14:42:56.647Z
Learning: In the Nuxt useAsyncData test "should watch params deeply in a non synchronous way", the foo watcher intentionally updates both params.foo and params.locale using locale.value, simulating a scenario where one watcher consolidates multiple reactive values into a shared params object for testing debounced/non-synchronous behavior.
Applied to files:
docs/3.api/2.composables/use-async-data.md
🪛 LanguageTool
docs/3.api/2.composables/use-async-data.md
[uncategorized] ~130-~130: Loose punctuation mark.
Context: ...options.timeout duration is exceeded ::warning [useAsyncData](/docs/4.x/api/...
(UNLIKELY_OPENING_PUNCTUATION)
🔇 Additional comments (5)
docs/3.api/2.composables/use-async-data.md (5)
19-26: Signal parameter added consistently to first example.Handler signature and $fetch call both properly use the signal parameter. No issues identified.
40-55: Watch params example properly threaded with signal support.Handler signature and $fetch call both correctly propagate the abort signal. Consistent with usage pattern.
194-202: Shared state examples updated consistently with signal support.Both "inconsistent" and "allowed" examples properly reflect the new handler signature with signal parameter. No issues identified.
228-241: Type definitions properly updated with AsyncDataHandler alias.New
AsyncDataHandler<ResT>type alias correctly documents the required handler signature, and bothuseAsyncDataoverloads are properly updated to reference it. Consistent with examples throughout the documentation.
125-131: Add blank line before::warningblock for proper Markdown rendering.Markdown block-level elements typically require separation from preceding content. Add a blank line before the
::warningmarker to ensure consistent rendering across different Markdown processors.Apply this diff:
- The `clear` function is called - The `options.timeout` duration is exceeded ::warning [`useAsyncData`](/docs/4.x/api/composables/use-async-data) is a reserved function name transformed by the compiler, so you should not name your own function [`useAsyncData`](/docs/4.x/api/composables/use-async-data). ::Likely an incorrect or invalid review comment.
Co-authored-by: Daniel Roe <[email protected]>
danielroe
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you! ❤️
🔗 Linked issue
related to nuxt/nuxt.com#2076
📚 Description
This PR adds the signal to all
useAsyncDatawith an abortable promise.