Add rethrow flag to createAsyncThunk

[msutkowski]

Addresses comments in #390. Usage would look like:

Sample action creator:

export const genericAxiosRequestThunk = createAsyncThunk(
  "app/dataFetched",
  async ({ httpMethod, path, baseUrl, data }) => {
    try {
      const result = await axios.request({
        method: httpMethod,
        url: `${baseUrl}/${path}`,
        data
      });
    return result.data;
  }
);

Usage in component:

    try {
      await dispatch(
        genericAxiosRequestThunk(
          {
            httpMethod: "POST",
            baseUrl: "https://mycoolapi.com/v1",
            path: "users",
            data: {
              email: "bademail",
              password: "short",
              first_name: "John",
              last_name: "Smith",
            }
          },
          true
        )
      );
    } catch (err) {
      console.log("Original error in component", err.response.data);
    }

Notes: I don't know if I really care for this being an extra argument. Would it make more sense to check in the args?

[netlify]

Deploy preview for redux-starter-kit-docs ready!

Built with commit f586dad

https://deploy-preview-391--redux-starter-kit-docs.netlify.com

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit f586dad:

Sandbox	Source
patient-rain-m11ks	Configuration
pensive-cherry-z6d13	Configuration
long-frost-zvevj	Configuration

[msutkowski]

Just some additional comments on this:

if you need to do more formatting, catch the error in the payload creator and re-throw with just the data you care about. in the same way that if you want to extract the data for the payload, you do that in the payload creator too

This idea is good but currently doesn't solve the given use case. The way that miniSerializeError currently works is limited in regards to handling more complex error types. While rethrow might not be the 'best option' per se, it at least gives the control of handling 100% back to the user. No matter what we do in the current situation, we're still going to have trouble handling errors and unwrapResulting them right now assuming anyone ever wants anything more than a basic HTTP error messages.

Will try to come up with some better ideas tomorrow.

[msutkowski]

Closing in favor of #393