2016-04-14 72 views
0

我正在用Redux构建一个包含使用计时器的库。我有一个动作创建者发送一个START_TIMER事件,还应该在计时器对象上调用start。代码如下所示:Redux中的回放操作

// thunk action creator 
 
const startTimer =() => (dispatch, getState) => { 
 
    
 
    if (!getState().timer.isRunning) 
 
    externalTimerObject.start() 
 

 
    dispatch({ 
 
    type: 'START_TIMER' 
 
    }) 
 
    
 
}

有两个问题,我试图解决:

  1. 如果我想记录我的行动到数据库或这样的localStorage我可以重播它们以达到一致的应用程序状态,即使rootState.timer.isRunning为真,我的计时器对象也不会运行。

  2. 条件if (!getState().timer.isRunning)要求我知道挂载根状态timer的位置。由于我将它作为库构建,所以我不能认为timer将始终直接挂载到根状态。

回答

1

如果我想记录我的行动到数据库或localStorage的,这样我可以重播他们得到一个一致的应用程序状态,那么即使rootState.timer.isRunning是真实的,我的计时器对象不会正在运行。

我认为这实际上是正确的设计。当您重现记录的日志时,您希望在发生的操作方面,发生的所有事情都与之前发生的一样发生在之间。例如,在回放操作的同时,您可能不希望从计算机中触发真正的AJAX请求,而是重播过去在该用户会话期间分发的记录的AJAX响应。

我认为计时器属于同一类别:从Redux的角度来看,行动历史记录描述了发生的副作用“结果”,并且重播动作应该足以让您的应用程序进入相同即使这些副作用实际上并没有再次发生。

条件if(!getState()。timer.isRunning)要求我知道挂载根状态计时器的位置。由于我将它构建为一个库,我不能认为定时器总是会直接挂载到根状态。

如果你正在建立一个库,你也可能不应该依赖于可用的thunk中间件。你似乎在你的动作创作者中依赖它。如果不理解你的确切用例,很难多说。