2016-02-23 70 views
0

假设我们有基于Redux的聊天应用程序。你会用什么策略来处理,例如,未传送的消息?我看到两种方式:在基于Redux的应用程序中处理请求错误

1.让用户发起消息重新发送。 它应该简化错误处理逻辑,但可能会对可用性产生负面影响。用户可能甚至没有注意到在多个频道/同时与多个人通话时有任何未传送的消息。

2.实施一个“工作人员”,将检查失败的消息,并会在一段时间后自动触发重新发送。在这种情况下,用户将需要较少的手动工作,但应用程序应该有一个更复杂的逻辑,我真的不知道如何将它与Redux结合在一起。

也可能有其他类型的数据请求失败。你将如何处理这样的错误?在Redux状态下有一系列序列化的失败请求在稍后重新发送是否是一个坏主意?

回答

2

我认为这两个用例都可以通过Redux Saga中间件来优雅地解决。它有一些初始的学习曲线(特别是如果你从未使用过发生器),但它可以让你描述可以“采取”你分派的动作的长时间运行的流程(“sagas”),根据它们做一些异步工作,使用控制流作为条件和循环,并在准备就绪时“放”结果行为。请参阅this answer以了解传奇故事。

或者,您可以查看Redux Loop,它扩展了减速器,除了状态更改之外,还能够返回“效果”。这使您可以从Reducer中“返回一个AJAX调用”,并继续这样做以响应操作,这也可以帮助您实现重试,尽管以更明确的方式。

1

这实际上并不在Redux的范围内,它更多地沿着redux-thunk寻求在异步功能方面提供的内容。

考虑到您的使用情况,您可以实施乐观呈现(即将所有消息视为成功,直到被证明为止),并且在发生故障时让您的分发调度回滚。

我的意思

// your actionCreator/thunk 
function (msg) { 
    return function(disptach, getState) { 
     // optimistic disptach 
     dispatch({ 
      type: "SEND_MESSAGE", 
      data: msg 
     }); 

     ajax({ 
      url: "https://someservice.com/sendMessage", 
      method: "POST", 
      data: msg, 
      onFailure: function(r) { 
       // handle failure with rollback 
       dispatch({ 
        type: "SEND_MESSAGE_FAILED", 
        data: msg, 
        meta: { 
         error: r.responseText 
        } 
       }); 
      } 
     }); 
    } 
} 

有了这样一个实现一个粗略的想法,那么你的第一个选项是比较合适的。向用户通知失败应由UI组件处理,该组件会对与消息传递错误有关的状态更改做出反应。

相关问题