Skip to content

Conversation

@OrbisK
Copy link
Member

@OrbisK OrbisK commented Oct 28, 2025

🔗 Linked issue

related to nuxt/nuxt.com#2076

📚 Description

This PR adds the signal to all useAsyncData with an abortable promise.

@OrbisK OrbisK requested a review from danielroe as a code owner October 28, 2025 13:56
@bolt-new-by-stackblitz
Copy link

Review PR in StackBlitz Codeflow Run & review this pull request in StackBlitz Codeflow.

@coderabbitai
Copy link

coderabbitai bot commented Oct 28, 2025

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 @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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.

📥 Commits

Reviewing files that changed from the base of the PR and between 4bc45c9 and 56a2aa8.

📒 Files selected for processing (1)
  • docs/3.api/2.composables/use-async-data.md (5 hunks)

Walkthrough

This 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

  • Verify the AsyncDataHandler<ResT> type alias precisely matches the handler shape: (nuxtApp: NuxtApp, options: { signal: AbortSignal }) => Promise<ResT>.
  • Confirm all updated useAsyncData overloads reference AsyncDataHandler and the signatures are consistent.
  • Check every example forwards { signal } to $fetch (correct placement and object syntax).
  • Review explanatory text and examples describing abort behaviour for clarity and correctness.
  • Files to spot-check: docs/1.getting-started/10.data-fetching.md, docs/2.guide/3.going-further/1.experimental-features.md, docs/3.api/2.composables/use-async-data.md, docs/3.api/2.composables/use-nuxt-app.md, docs/3.api/2.composables/use-nuxt-data.md, docs/3.api/2.composables/use-request-fetch.md.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Title Check ✅ Passed The PR title "docs: add signal support to useAsyncData examples" directly corresponds to the changeset, which updates documentation files across multiple composables to thread AbortController signals through useAsyncData handler functions and subsequent $fetch calls. The title follows conventional commit format with the "docs:" prefix and clearly identifies the primary change as adding signal support to useAsyncData examples. The title is concise, specific, and enables a teammate reviewing the history to understand the core purpose of the changes.
Description Check ✅ Passed The PR description states "This PR adds the signal to all useAsyncData with an abortable promise," which is clearly related to the changeset. The description accurately reflects that the changes involve adding signal support to useAsyncData examples across documentation files, enabling request cancellation. Although the description is brief, it is directly relevant to the changes and not off-topic, meeting the lenient criteria for this check that requires only basic topical relevance regardless of detail level.

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a 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

📥 Commits

Reviewing files that changed from the base of the PR and between 39f3039 and a8487d6.

📒 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 $fetch call, setting a good precedent for subsequent examples.


46-56: Watch Params example correctly uses signal.

The example properly demonstrates signal usage alongside other $fetch options like params. 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.

Comment on lines 75 to 131
### 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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

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:

  1. Line 90 has a trailing space (should be removed)
  2. Line 131 has a formatting issue with the opening ::warning marker (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.

Suggested change
### 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.

Copy link

@coderabbitai coderabbitai bot left a 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

📥 Commits

Reviewing files that changed from the base of the PR and between a8487d6 and 63812ce.

📒 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 $fetch alongside 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 ::warning marker. 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

::warning

This 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 an AbortSignal via the options parameter. 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.

Copy link

@coderabbitai coderabbitai bot left a 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

📥 Commits

Reviewing files that changed from the base of the PR and between 63812ce and 4bc45c9.

📒 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 both useAsyncData overloads are properly updated to reference it. Consistent with examples throughout the documentation.


125-131: Add blank line before ::warning block for proper Markdown rendering.

Markdown block-level elements typically require separation from preceding content. Add a blank line before the ::warning marker 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.

Copy link
Member

@danielroe danielroe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you! ❤️

@danielroe danielroe merged commit 5f82e63 into nuxt:main Oct 28, 2025
8 of 9 checks passed
@github-actions github-actions bot mentioned this pull request Oct 28, 2025
@github-actions github-actions bot mentioned this pull request Nov 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants