使用 Redux，错误消息在哪里产生最好？答案

【问题标题】：With Redux where are error messages best produced?使用 Redux，错误消息在哪里产生最好？
【发布时间】：2016-04-28 04:28:15
【问题描述】：

我最近在一个 ReactJS 项目中使用 Redux，我遇到了一个有趣的情况，我需要生成某种类型的错误消息显示给用户。这些可能是消息的验证错误类型，也可能是报告系统状态的消息。可能没有规定的方法可以做到这一点，但我很好奇的是是否将确定错误消息的逻辑放入我的减速器或由我的减速器引用，或者是否将其放置在我的 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>

其他选项？

也有可能我遗漏了与下面两个示例不同的其他模式或解决方法。如果是这样，并且有令人信服的理由这样做，那也很好。

【问题讨论】：

标签： error-handling reactjs redux

【解决方案1】：

支持让消息内容更靠近视图的论据：

在错误消息中处理超链接和其他与文本样式相关的方面可能会使视图更适合定位这些转换或至少定位将作为结果显示的内容。
如果我们比较预期错误代码的类型而不关注消息的措辞，围绕减速器编写单元测试可能会更容易理解。
本地化可能需要配置和其他可能不属于纯函数类别的值。
自动化的测试用例不需要被本地化的具体细节弄得一团糟。

支持将消息内容更接近化简器的论点：

如果您对 reducer 进行单元测试，因为其功能简单，您可以在不测试视图的情况下获得更多应用程序逻辑的覆盖范围。
将逻辑组织到 reducer 中并使视图更加贫乏，可能会使开发人员更容易预测在哪里可以找到每种类型的代码。
如果将任何自定义本地化逻辑保存在 reducer 中，它可能更易于调试或测试。

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

我确定我遗漏了其他几个重要方面，但这是我能想到的。

【讨论】：