docs: document 'pending' as alias of status === 'pending' #33221
Conversation
|
|
|
Caution Review failedThe pull request is closed. WalkthroughAdds a new Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Areas to check during review:
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
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.
Actionable comments posted: 0
🧹 Nitpick comments (4)
docs/3.api/2.composables/use-async-data.md (4)
21-25: Showpendingin the destructure, not only as a comment.Make
pendingdiscoverable by including it in the example destructure.-const { data, status /* pending (alias) */, error, refresh, clear } = await useAsyncData( +const { data, status, pending, error, refresh, clear } = await useAsyncData(
33-34: Clarify ref unwrapping in templates.Small wording tweak to mention auto-unwrapping in templates.
-`data`, `status`, `pending` and `error` are Vue refs and they should be accessed with `.value` when used within the `<script setup>`, while `refresh`/`execute` and `clear` are plain functions. +`data`, `status`, `pending` and `error` are Vue refs and should be accessed with `.value` in `<script setup>` (auto-unwrapped in templates). `refresh`/`execute` and `clear` are plain functions.
118-119: Minor phrasing polish for readability.Tighten the parenthetical about
pending.-When using the same key for multiple `useAsyncData` calls, they will share the same `data`, `error` and `status` refs (and `pending`, as it derives from `status`). This ensures consistency across components but requires option consistency. +When using the same key for multiple `useAsyncData` calls, they share the same `data`, `error` and `status` refs (and `pending`, which derives from `status`). This ensures consistency across components but requires option consistency.
209-211: Confirmed: AsyncData.pending present in source; align docs generics
- packages/nuxt/src/app/composables/asyncData.ts — contains
pending: Ref<boolean>(≈ line 118) andexport type AsyncData<Data, Error> = _AsyncData<Data, Error> & Promise<_AsyncData<Data, Error>>(≈ line 126).- Docs use
DataE/ErrorT— update docs toData/Erroror rename the source generics for consistency.- No JSDoc alias
computed(() => status.value === 'pending')found in the source; add that comment to the implementation or remove it from the docs to avoid drift.
📜 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
🧠 Learnings (1)
📚 Learning: 2025-09-10T14:42:56.613Z
Learnt from: Tofandel
PR: nuxt/nuxt#33192
File: test/nuxt/use-async-data.test.ts:366-373
Timestamp: 2025-09-10T14:42:56.613Z
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
🔇 Additional comments (1)
docs/3.api/2.composables/use-async-data.md (1)
161-163: LGTM:pendingreturn value documented clearly.Accurately describes
pendingas an alias ofstatus === 'pending'.
827568a to
77d24a8
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
docs/3.api/2.composables/use-async-data.md (3)
21-21: Showpendingin the destructuring for clarityReaders may miss that
pendingis available if it’s only mentioned in a comment. Explicitly destructure it.-const { data, status /* pending (alias) */, error, refresh, clear } = await useAsyncData( +const { data, status, pending, error, refresh, clear } = await useAsyncData(
33-33: Tighten copy; clarify template accessMinor wording polish and note that
.valueisn’t needed in templates.-`data`, `status`, `pending` and `error` are Vue refs and they should be accessed with `.value` when used within the `<script setup>`, while `refresh`/`execute` and `clear` are plain functions. +`data`, `status`, `pending` and `error` are Vue refs; in `<script setup>` access them with `.value` (in templates you can omit `.value`). `refresh`/`execute` and `clear` are plain functions.
161-162: Make the alias phrasing more directSmall style tweak.
-- `pending`: a `Ref<boolean>` that is `true` while the request is in progress. - This is effectively an alias of `computed(() => status.value === 'pending')`. +- `pending`: a `Ref<boolean>` that is `true` while the request is in progress. Alias of `computed(() => status.value === 'pending')`.
📜 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
🧠 Learnings (1)
📚 Learning: 2025-09-10T14:42:56.613Z
Learnt from: Tofandel
PR: nuxt/nuxt#33192
File: test/nuxt/use-async-data.test.ts:366-373
Timestamp: 2025-09-10T14:42:56.613Z
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
🔇 Additional comments (2)
docs/3.api/2.composables/use-async-data.md (2)
118-118: Good clarification thatpendingis shared viastatusThis makes the sharing model explicit and avoids confusion.
209-210: Docs vs code parity: confirmAsyncDataalready exposespendingThe PR description says docs‑only; ensure the runtime/types already include
pendingso the docs don’t get ahead. The AI summary claims a code change addingpendingto the public type, which isn’t present in this PR.Run to verify the type in the repo:
#!/bin/bash # Find AsyncData definitions and check for `pending: Ref<boolean>` rg -nP -C3 '(type|interface)\s+AsyncData\b' -g '!**/dist/**' -g '!**/node_modules/**' rg -nP -C2 '\bpending:\s*Ref<\s*boolean\s*>' -g '!**/dist/**' -g '!**/node_modules/**'
3f68535 to
82ec0dd
Compare
82ec0dd to
0daf23f
Compare
danielroe
left a comment
There was a problem hiding this comment.
Thank you! and apologies for the delay on this one.
Co-authored-by: PaulyBearCoding <PaulyBearCoding@users.noreply.github.com>
🔗 Linked issue
Resolves #32956.
Related: #32959 (initial deprecation doc PR), #32960 (v5 cleanup discussion).
Resolves: #33571
closes #33594
📚 Description
Summary
Document
pendingonuseAsyncDataas an alias ofstatus === 'pending', per the maintainers’ direction to keep and document it.What changed
pendingto the refs note (Usage section), alongsidedata,status, anderror.pending(Ref<boolean>) with an explicit note: it’s effectivelycomputed(() => status.value === 'pending').pendingis shared as it derives fromstatus.AsyncDatatype shape with:Why
pendingexists in the interface and is widely used, but it wasn’t visible in the docs. This PR closes that documentation gap and aligns the page with current behavior (keep & document, not deprecate). It should reduce confusion and improve DX.Notes
Suggested PR title (Conventional Commits)
docs(asyncData): document 'pending' as alias of status === 'pending'