v1.3.0-alpha.2
Pre-releaseThis alpha release alters the error-handling behavior of createAsyncThunk
.
Changes
createAsyncThunk
Error Handling
createAsyncThunk
catches rejected promises from the promise payload callback, and dispatches a "rejected"
action in response with the error value. That means that the thunk itself always returns a resolved promise.
We had a request to re-throw errors from the thunk, in case the calling code wants to chain off the promise or handle it further, so we've implemented that.
We've also removed the "finished"
action that was previously being dispatched in a finally {}
clause at the end, as it shouldn't truly be necessary - app logic should just need to respond to either the "fulfilled"
or "rejected"
actions.
When an error is caught in the thunk, we try to put it into the "rejected"
action. But, since JS Error
objects aren't actually serializable, we now check for Error
objects and serialize them into plain JS objects with any of the relevant fields ( {name?, message?, stack?, code?}
), or just the value itself if it's not an Error
. Unfortunately, since the err
value in a catch(err) {}
clause doesn't have a type, the action.error
field will come through as a type of any
either way.
Finally, we've reordered the logic inside to avoid cases where an error while dispatching "success" gets swallowed and triggers the "AJAX failed" handling.