With Redux where are error messages best produced? - error-handling

Question

I've been using Redux recently on a ReactJS project and I've come cross an interesting situation where I need to generate some type of error message that is shown to the user. These could be validation error types of messages or possibly messages that report on the state of the system. There may be no perscribed way to do this but what I'm curious about is whether to put the logic which determines the error message into my reducers or referenced by my reducers or whether to place it in my ReactJS components.
Transform error codes into messages
const getIrsFormSubmissionErrorMessage = (errorCode) => {
switch(errorCode) {
case "server_error": return "Your submission failed because of a problem on the server";
case "authorization_failure": return "You are not allowed to submit this form.";
case "validation_error": return "One or more of the values entered are invalid.";
case undefined: return undefined;
default: return "Your submission failed, please contact support.";
}
}
Ex. 1 Error messages derived in reducer and shown in component:
function irsForm(state, action) {
switch (action.type) {
case "SUBMIT_IRS_FORM_FAILED":
return {
...state,
submitRequest: {
executing: false,
errorMessage: getIrsFormSubmissionErrorMessage(action.errorCode)
},
};
default:
return state;
}
}
const FormError = (props) =>
<span className="form-error">{props.errorMessage)<span>
Ex. 2 Error messages derived in component:
function irsForm(state, action) {
switch (action.type) {
case "SUBMIT_IRS_FORM_FAILED":
return {
...state,
submitRequest: {
executing: false,
errorMessage: action.errorCode,
},
};
default:
return state;
}
}
const FormError = (props) =>
<span className="form-error">{getIrsFormSubmissionErrorMessage(props.errorCode)}<span>
Other options?
It's also possible that I'm missing some other pattern or way of going about this that is different from the two examples below. If that's the case and there is a compelling reason to do it that way then that would be great too.

Answer 1

Arguments in favor of putting message content closer to the view:
Handling hyper-links and other styling related aspects of text within error messages may make the view a better place to locate these transformations or at least the content that will be displayed as a result.
Writing unit tests around the reducer will likely be easier to comprehend if we compare the types of expected error codes and not focus on the phrasing of the message.
Localization may require configuration and other types of values which may not be in the category of pure functions.
Automated test cases won't need to be cluttered with localization specific details.
Arguments in favor of putting message content closer to the reducers:
If you are unit testing reducers because of their functional simplicity you get more coverage over this part of your application logic without testing your views.
Organizing logic into reducers and making views more anaemic may make it easier for developers to predict where to find each type of code.
Any custom localization logic may be easier to debug or test if it is kept within reducers.
These arguments remind me of a few related things from both DDD (Domain Driven Design) and CQRS (Command Query Responsibility Segregation). In DDD there is sometimes debate on whether or not and to what degree view only data should be present on object within the domain model. If a property/field/data isn't used to identify or to support the domain logic itself then should it be along for the ride? With CQRS it's a even though reads writes have already been agreed to be separated I think there is varying degrees in which you can denormalize the read-models which are created in response to the domain events. Examples can range from a read model that exists in a Relational Database to a set of statically generated web pages.
I'm sure I'm left out several other important aspects but this is what I could come up with off the top of my head.