Skip to content
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

Minor RTK mutation function call fix #4577

Open
weixin-tan opened this issue Jul 2, 2023 · 1 comment
Open

Minor RTK mutation function call fix #4577

weixin-tan opened this issue Jul 2, 2023 · 1 comment

Comments

@weixin-tan
Copy link

What docs page needs to be fixed?

  • Section: Redux Essentials
  • Page: Part 8 RTK Query Advanced Patterns

What is the problem?

Seems like a minor typo/missing function call in the usage of mutation function. In part 7, it is stated that the .unwrap() function needs to be called for the RTK mutation query.

As with the thunk dispatch, we call addNewPost with the initial post object. This returns a special Promise with a .unwrap() method, and we can await addNewPost().unwrap() to handle any potential errors with a standard try/catch block.

Whereas in part 8 code snippet for Editing Post, the .unwrap() call is missing for a very similar mutation function.

  const [updatePost, { isLoading }] = useEditPostMutation()

  /* code omitted */

  const onSavePostClicked = async () => {
    if (title && content) {
      await updatePost({ id: postId, title, content }) // <- this should have a .unwrap() ?
      history.push(`/posts/${postId}`)
    }
  }

What should be changed to fix the problem?

Add .unwrap() to the code snippet

@EskiMojo14
Copy link
Contributor

adding unwrap is a specific choice for the call site - by default, the promise will not reject regardless of whether the request succeeded or not.

calling unwrap makes it so it will reject the promise for an unsuccessful request, which means you should be adding specific error handling (.catch or try catch) for that promise rejection.

calling a trigger without unwrapping essentially says "i don't care if the request succeeds or not, i just want to try it - I'll probably handle the failure via the hook result instead". this is a valid choice, and likely the one this example is conveying.

when you add an unwrap without handling the error it might throw, you'll end up with logged errors about an unhandled promise rejection, which is usually undesirable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants