使用Redux哪里有最好的错误消息？

Question

我最近在ReactJS项目上使用Redux，我遇到了一个有趣的情况，我需要生成一些向用户显示的错误消息。这些可能是消息的验证错误类型，也可能是报告系统状态的消息。可能没有任何方法可以做到这一点，但我很好奇的是，是否将确定错误消息的逻辑放入我的Reducer或者我的reducer引用或是否将它放在我的ReactJS组件中。

将错误代码转换为消息

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.";
    }
}

实施例。 1在reducer中派生的错误消息，显示在组件中：

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>

实施例。 2在组件中导出的错误消息：

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>

其他选择？

我也可能缺少一些与下面两个例子不同的其他模式或方法。如果是这种情况并且有一个令人信服的理由这样做，那么这也会很棒。

Answer 1

支持将消息内容放在视图附近的参数：

1. 在错误消息中处理文本中的超链接和其他与样式相关的方面可能会使视图成为查找这些转换的最佳位置，或者至少是因此显示的内容。
2. 如果我们比较预期错误代码的类型而不是关注消息的措辞，那么围绕减速器编写单元测试可能会更容易理解。
3. 本地化可能需要配置和其他类型的值，这些值可能不属于纯函数类别。
4. 自动化测试用例不需要与本地化特定细节混杂在一起。

支持将消息内容放在reducers附近的参数：

1. 如果您因为功能简单而对减速器进行单元测试，则可以在不测试视图的情况下更好地覆盖应用程序逻辑的这一部分。
2. 将逻辑组织到Reducer中并使视图更加贫乏可能使开发人员更容易预测在哪里找到每种类型的代码。
3. 如果将任何自定义本地化逻辑保存在Reducer中，则可能更容易调试或测试。

这些论点让我想起DDD（域驱动设计）和CQRS（命令查询责任隔离）中的一些相关内容。在DDD中，有时会出现关于是否以及在何种程度上仅在域模型中的对象上存在数据的争论。如果不使用属性/字段/数据来识别或支持域逻辑本身，那么它应该用于骑行吗？使用CQRS，尽管已经同意将读取写入分开，但我认为在不同程度上您可以对响应于域事件而创建的读取模型进行非规范化。示例的范围可以从存在于关系数据库中的读取模型到一组静态生成的网页。

我确信我已经遗漏了其他几个重要方面，但这是我能想到的最重要的事情。