假设我们有一个基于 Redux 的聊天应用程序。例如，您将使用什么策略来处理未传递的消息？我看到两种方法:
1.让用户发起消息重发。
它应该简化错误处理逻辑，但可能会对可用性产生负面影响。用户在多个 channel /同时与多个人交谈时甚至可能没有注意到有任何未传递的消息。
2. 实现一个“worker”，它将检查失败的消息并偶尔触发自动重新发送。 在这种情况下，用户将需要更少的手动工作，但应用程序应该有更复杂的逻辑，我真的不明白如何将它与 Redux 结合在一起。
对其他类型数据的请求也可能失败。您将如何处理此类错误？在 Redux 状态下有一个序列化的失败请求池以便稍后重新发送是不是一个坏主意？
最佳答案
我认为这两个用例都可以通过 Redux Saga 优雅地解决。中间件。它有一些初始的学习曲线(特别是如果您从未使用过生成器)，但它可以让您描述可以“采取”您调度的操作的长时间运行的流程(“sagas”)，基于它们执行一些异步工作，使用控制流等作为条件和循环，并在它们准备好时“放置”结果 Action 。另见 this answer介绍 sagas。
或者，您可以查看 Redux Loop它扩展了 reducer，除了状态更改之外，还具有返回“效果”的能力。这使您可以从 reducer “返回 AJAX 调用”，并继续这样做以响应操作，这也可以帮助您实现重试，尽管是以更明确的方式。
关于error-handling - 处理基于 Redux 的应用程序中的请求错误，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/35579506/