Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Rejecting responses with HTTP failure codes has unfortunate consequences

See original GitHub issue

Thanks for making restful-react! It’s a great library and tool (I’m using it to generate code from an OpenAPI spec).

I really like how useGet works:

  1. The promise never rejects, so you can await on it safely without it throwing an error
  2. It’s easy to check if data or error is defined, and then act on it. (If I was to change anything, there are some cool things you can do with conditional types, so that the compiler can automatically infer that data or error is defined, but never both)

However, useMutate has some drawbacks:

  1. The promise can throw, meaning that await is not safe without appending an empty .then clause:
    await useMutate("path", props).catch(() => { /* pass */})
    Furthermore, even though the error field from useMutate is of type GetDataError<TError>, the compiler cannot infer that in the promise rejection clause, because failed promises can contain anything.
  2. There’s no data field, to accompany error. That means that I’ll have to use two mechanisms: await on mutate to read the result of my operation, and check error for any failures.

I’d think it would make a lot of sense for useMutate to be more similar to useGet:

  1. The promise returned by mutate should never reject, and also resolve to void
  2. A new field data: TData | null should be added, to mirror the existing error.

Do you have any thoughts on this? I’d be happy to contribute some code to implement this functionality.

Issue Analytics

  • State:open
  • Created 4 years ago
  • Reactions:1
  • Comments:7 (5 by maintainers)

github_iconTop GitHub Comments

torkelrogstadcommented, Feb 18, 2020

What do you think of this?

const MyComp = () => {
  const { mutate: createResource, data, error } = useMutate();

  return (
      onClick={async () => {
        await createResource()
        if (error) {
          return dispatch("error", error) // error has type GetDataError<TError>
        dispatch("success", data))

It very closely mimics useGet, which I think is good for two reasons:

  1. useGet has a very pleasant API
  2. Consistency is always good:-)
TejasQcommented, Jun 26, 2020

Thank you so much, @torkelrogstad!

Read more comments on GitHub >

github_iconTop Results From Across the Web

Ignore HTTP Client Errors At Your Peril
All of this means that somebody is seriously misinterpreting what your server expects to receive. That usually means a major bug in either...
Read more >
HTTP response status codes - MDN Web Docs - Mozilla
HTTP response status codes indicate whether a specific HTTP request has been successfully completed. Responses are grouped in five classes:
Read more >
HTTP Status Codes and SEO: what you need to know
HTTP status codes are three-digit responses a server returns at the request of a client (a browser or search engine).
Read more >
RFC 7231: Hypertext Transfer Protocol (HTTP/1.1)
If the request method is GET or HEAD and the response status code is 200 (OK), ... Failure to do so will result...
Read more >
Best Practices for API Error Handling - Nordic APIs
Error codes in the response stage of an API is the fundamental way in ... There are certain implications for each of the...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found