docs(query-core): add JSDoc for 'MutationOptions' - #11550
Conversation
|
View your CI Pipeline Execution ↗ for commit e3e090e
☁️ Nx Cloud last updated this comment at |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: TanStack/query/.coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (120)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthroughThe change adds JSDoc descriptions to ChangesMutation documentation synchronization
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~15 minutes Change: Other 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 |
🚀 Changeset Version Preview1 package(s) bumped directly, 24 bumped as dependents. 🟩 Patch bumps
|
size-limit report 📦
|
e3e090e to
00d865b
Compare
🎯 Changes
MutationOptionsdocuments 5 of its 13 properties, whileQueryOptionsdocuments 17 of 17. The eight without a comment are the ones people actually pass touseMutation—mutationFn,mutationKey,onMutate,onSuccess,onError,onSettled,metaandscope— so every generated options table renders them with an empty description:mutationFn?(variables, context) => Promise<TData>onMutate?(variables, context) => ...This adds JSDoc for those eight in
query-core, which fills the column across all seven adapters. Empty description cells across the generated reference drop from 191 to 63 — the rest areinitialPageParamand a few re-declared properties, left for a follow-up.The text is recovered from the hand-written
useMutation.mdthat the TypeDoc migration (#11366) deleted, rewritten in the sentence style the surrounding JSDoc already uses rather than v4's bullet lists.Every statement was checked against the implementation
The v4 page turned out to be wrong in one place, so provenance alone wasn't enough:
scope— v4 said "Defaults to a unique id (so that all mutations run in parallel)". Nothing generates an id:scopeFor()returnsmutation.options.scope?.id, andcanRun()lets an unscoped mutation start immediately. The observable behaviour is the same, but the mechanism isn't, so this one is written from the implementation instead.The other seven check out:
mutationFnis optional when a default is registeredQueryClient.setMutationDefaultsmutationKeyis used to match mutationsmatchMutationinutils.tsonMutate's promise is awaited beforemutationFnawait this.options.onMutate?.()inmutation.tsonMutate's return value reaches the other callbacksonMutateResultonSuccess/onErrorare awaited beforeonSettledonSuccess→onSettledordering inmutation.tsonSettledis awaited before the mutation settlesawait onSettledprecedesdispatch({ type: 'success' })metais readable fromMutationCachecallbacksonError/onSuccessonMutationCacheConfigVerification
pnpm --filter @tanstack/query-core run test:typespasses on TS 5.6 through 7.0The source change is comments only; no type or runtime behaviour changes.
✅ Checklist
pnpm run test:pr, or these tests do not apply to this pull request.🚀 Release Impact
Summary by CodeRabbit