如何以可维护的方式使用React和Redux thunk处理服务器/连接异常

How to handle server/connection exceptions with React and Redux thunk in a maintainable manner

本文关键字：处理 thunk Redux 服务器 异常 连接 React 维护 方式使      更新时间：2023-09-26

我使用Redux thunk来调度异步操作，如获取和发布到服务器。每个动作创建者调用都返回一个promise，当ajax完成了它的魔力，并且Redux实际上已经根据ajax的成功/失败调度了正确的动作来更新状态时，这个promise就会解析。通过这种方式，我们可以在组件级别自定义调度后回调。

doPostActionCreator(data) {
  return dispatch => {
    return httpService.post(data) {
      .then(response => {
        dispatch({type: POST_SUCCESS, data: response})
        return response
      })
      .catch(error => {
        dispatch({type: POST_ERROR})
        return error
      )}
    }
  }
}

--

componentsDoPostHandler(data) {
  this.props.doPostActionCreator(data)
    .catch(error => {
      alert(error)
      this.setState({...})
    })
}

这个简单的例子一切都很好，但当我试图通过这种模式引入真正的错误处理逻辑时，比如从catch中递归调用componentsDoPostHandler，并在计数器限制超过时中断，事情开始看起来很糟糕，很难维护，也很容易中断。更复杂的是，在我的现实世界场景中，this.props.doPostActionCreator实际上是fetchCsrfTokenActionCreator的回调，它本身需要相同的错误处理逻辑，尝试获取X次，如果失败，则执行其他操作。现在，如果一个页面包含两个不同的容器，并且它们都引入了这种逻辑，那么在第一个容器已经执行了恢复之后，就不可能取消后者的恢复操作了，因为一旦调用了操作创建者，就无法取消。最后，很难理解程序是如何工作的，"不同步"的操作问题开始出现，使应用程序处于不一致的状态，这些问题很难跟踪。

这让我怀疑，从动作创建者那里返回承诺是否真的是一种反模式，最终导致无法维护的代码。我没有找到任何真实世界中如何使用React/Redux堆栈处理异步服务错误的例子。我做错了吗？有没有一种更干净的方法来处理异步异常（理想情况下尝试X次，提醒用户并返回登录页面），保持一切一致、易于理解、维护并避免异步混乱？

任何关于该主题的真实世界的例子都将受到高度赞赏

我相信您可以在操作创建者内部处理所有重试逻辑。也就是说，我认为您不需要返回任何内容来尝试从组件调用.catch()，或者无论您在哪里调用动作创建者。记住，你也可以访问thunk中的getState()方法，比如说在你的动作创建者的.post().catch()中，你总是可以调度一些东西来指示某个东西失败了，这可能会由一个跟踪失败次数的reducer来处理，然后在调度之后调用.getState()，查看有多少失败，并决定从那里做什么（即重试，或者可能调度另一个操作，指示某个操作失败了太多次，这将更新您的状态并允许您的组件从该状态呈现）。

我认为，除了动作创作者之外，不必担心.catch()，你会简化你所看到的问题。如果您希望它出现在多个操作创建者中，您也许可以将其抽象为API调用方方法，该方法为您处理此逻辑。

相关文章：