docs(toolkit): unwrap updatePost mutation in Part 8 edit form example

[trinadhkoya]

Checklist

• Is there an existing issue for this PR?
  • Closes Minor RTK mutation function call fix #4577
• Have the files been linted and formatted?
  • The edited lines follow the repo Prettier config (semi: false, singleQuote: true) and match the existing Part 7 example. I intentionally did not run Prettier across the whole file — master's copy of this page already has pre-existing formatting deviations, so a full reformat would balloon the diff well beyond this focused fix (per CONTRIBUTING: "try to keep your pull request focused in scope").

What docs page needs to be fixed?

• Section: Redux Essentials
• Page: Part 8: RTK Query Advanced Patterns (docs/tutorials/essentials/part-8-rtk-query-advanced.md)

What is the problem?

In the EditPostForm example, the updatePost mutation is awaited without calling .unwrap():

if (title && content) {
  await updatePost({ id: post.id, title, content })
  navigate(`/posts/${postId}`)
}

This is inconsistent with what the tutorial teaches. Part 7 explicitly explains that the mutation trigger returns "a special Promise with a .unwrap() method" that you await inside a try/catch to handle request errors, and the AddPostForm example there does exactly that. As written, the Part 8 edit example swallows a failed request and navigates away as if the edit succeeded.

What changes does this PR make to fix the problem?

Mirrors the Part 7 pattern in the Part 8 EditPostForm example — wraps the call in try/catch, adds .unwrap(), navigates only on success, and logs on failure:

if (title && content) {
  try {
    await updatePost({ id: post.id, title, content }).unwrap()
    navigate(`/posts/${postId}`)
  } catch (err) {
    console.error('Failed to save the post: ', err)
  }
}

This keeps error handling consistent across both the add and edit forms in the Essentials tutorial. If maintainers prefer the more minimal change of only appending .unwrap() (without the surrounding try/catch), I'm happy to adjust.

[netlify]

✅ Deploy Preview for redux-docs ready!

Name	Link
🔨 Latest commit	d5ca742
🔍 Latest deploy log	https://app.netlify.com/projects/redux-docs/deploys/6a955289e9d23d0008b9341e
😎 Deploy Preview	https://deploy-preview-4918--redux-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[trinadhkoya]

Hi @timdorr — small docs-only change (unwraps the updatePost mutation in the Part 8 edit-form example). Whenever convenient, a quick look would be appreciated. Thanks!

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/redux@d5ca742 -D

yarn add https://pkg.pr.new/redux@d5ca742.tgz -D

pnpm add https://pkg.pr.new/redux@d5ca742.tgz -D

bun add https://pkg.pr.new/redux@d5ca742.tgz -D

commit: d5ca742

[aryaemami59]

Seems like this was already attempted at #4578, which was closed unmerged for the reasons highlighted here, as well as a more thorough explanation posted here.

Worth noting they aren't identical though. #4578 only appended .unwrap() by itself, and one of the objections was that unwrapping without handling the rejection ends up logging unhandled promise rejections, which the try/catch here does address. What still seems to apply is that leaving out .unwrap() is a deliberate call site choice, and Part 8 might be demonstrating exactly that. Also the fallback mentioned in the description (.unwrap() without the try/catch) is pretty much the exact shape that already got declined.

[trinadhkoya]

Thanks for digging up the history, @aryaemami59 — I hadn't seen #4578, Mark's note there, or @EskiMojo14's explanation on #4577.

First, let me withdraw the fallback I offered in the description: appending .unwrap() without the try/catch is exactly the shape that was declined in #4578, and for good reason — an unhandled rejection is worse than the current behavior. That option is off the table.

On the objection that still applies: I agree that leaving out .unwrap() is a valid, deliberate call-site choice, and if Part 8 is intentionally demonstrating that pattern, this PR shouldn't erase it. But nothing on the page signals that intent. Part 7 introduces .unwrap() specifically as the way to handle mutation errors in a form ("we can await addNewPost().unwrap() to handle any potential errors with a standard try/catch block"), and the AddPostForm example does exactly that. Then Part 8's EditPostForm drops it silently and navigates to the post page even when the save failed. To a learner following the tutorial sequentially, that reads as a bug rather than a teaching moment — #4577 itself was filed out of exactly that confusion.

So I see two ways to resolve this, and I'm happy with either:

1. This PR as-is — mirror the Part 7 pattern so error handling is consistent across the two forms, since the rejection is now actually handled.
2. A docs note instead — if the omission is deliberate, keep the code unchanged and add a short callout in Part 8 explaining that the mutation promise always resolves and that .unwrap() is an opt-in for call-site error handling (with a pointer back to Part 7). That would genuinely close Minor RTK mutation function call fix #4577, since the confusion is about the why, not the code.

Happy to rework this PR into option 2 if that's the direction you and @markerikson prefer.