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.
case `${RECEIVE_POSTS}_REJECTED`:
return Status.REJECTED;
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).
dispatch(myAsyncActionCreator()).catch(function(error) {
// do something with the error
})
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!
I find it easier to reason about following redux-thunk
code compared to the redux-promise-middleware
automagical type modifications... so posting as an alternative, in case other people find the comparison useful too:
export const fetchPosts = () => (dispatch) => {
dispatch({type: '${RECEIVE_POSTS}_PENDING'})
contentfulClient.getEntries()
.then(data => dispatch({type: '${RECEIVE_POSTS}_FULFILLED', payload: data.items})
.catch(error => dispatch({type: '${RECEIVE_POSTS}_REJECTED', payload: error})})
}
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With