Rejecting responses with HTTP failure codes has unfortunate consequences

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.

[torkelrogstad]

What do you think of this?

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

  return (
    <Button
      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:-)

[TejasQ]

Thank you so much, @torkelrogstad!