So basically I am dispatching an action with thunk and redux-promise-middleware, which makes an API call that returns a promise. I then send the promise returned to another action creator as a 'payload' argument, which works with the redux-promise-middleware and handles different actions MY_ACTION_TYPE_PENDING or MY_ACTION_TYPE_REJECTED or MY_ACTION_TYPE_FULFILLED. My question is do I handle the errors in reducer via the _REJECTED action and not catch it on my dispatch(actionCreator(payload)? When I do not catch the error on my dispatch I get a warning in the console, despite my reducer handling the error well with the _REJECTED ACTION.
Below are some of my actions:
export const RECEIVE_POSTS = 'RECEIVE_POSTS';
export const receivePosts = (data) => ({
type: RECEIVE_POSTS,
payload: data
})
// thunk middleware for fetching blog
export const fetchPosts = () => {
return (dispatch) => {
const payload = contentfulClient.getEntries().then(
data => data.items,
error => console.log('An error occurred in fetchPost thunk middleware', error)
)
return dispatch(receivePosts(payload))
.catch((error) => {
console.log('caught error in fetchPost', error)
})
}
}
then this is some of my blog reducers file, it handles the actions the promise middleware sends out
const status = (state = Status.IDLE, action) => {
switch (action.type) {
case `${RECEIVE_POSTS}_PENDING` :
return Status.PENDING;
case `${RECEIVE_POSTS}_FULFILLED`:
return Status.FULFILLED;
case `${RECEIVE_POSTS}_REJECTED`:
return Status.REJECTED;
default:
return state
}
}
const error = (state = null, action) => {
switch (action.type) {
case `${RECEIVE_POSTS}_REJECTED`:
return action.payload.message
default:
return state;
}
}
This is a good question and I don't think there is one answer. Ultimately, it is up to the developer or development team. As a practice, I would argue, yes, promise errors should be handled/caught at the dispatch. Here's why...
In your example, you don't catch the promise error. You, as you explained, only handle the error in your reducer.
You read an object with the type
${RECEIVE_POSTS}_REJECTED
and write changes to the state. When you write changes to the state, you (presumably update UI and/or dispatch side effects to handle the error. This is a typical implementation for Redux.The actual promise, however, remains uncaught in this implementation. In order to catch the promise error, you need to do so at dispatch (or in a middleware).
If you catch the error at dispatch, you won't see an error in the console. Verbose, yet straightforward/explicit, this practice makes it clear to other developers how errors are handled. I believe clarity is important for maintainability and future changes, hence why I argue for catching errors at dispatch.
Hope that helps!