Javascript 误用Redux减缩器的现实后果?

Javascript 误用Redux减缩器的现实后果?,javascript,redux,Javascript,Redux,我继承了一个Redux代码库,发现一些代码违反了Redux的基本规则:在减缩器中并没有副作用 具体来说,有一个跟踪减速器,它看起来像这样: function tracking(state = {}, action) { function sendEvent(event, data) { // API call here to send a tracking event } switch (action.type) { case TRACK_FRIEND_REQUES

我继承了一个Redux代码库,发现一些代码违反了Redux的基本规则:在减缩器中并没有副作用

具体来说,有一个
跟踪
减速器,它看起来像这样:

function tracking(state = {}, action) {
  function sendEvent(event, data) {
    // API call here to send a tracking event
  }

  switch (action.type) {
    case TRACK_FRIEND_REQUEST:
      sendEvent('track-friend-request', action.payload);
      return state;

    case TRACK_LINK_CLICK:
      sendEvent('link-click', action.payload);
      return state;
  }
}
这显然是错误的;国家是没有意义的,它的存在只是因为它的副作用。正确的解决方案(IMO)是创建一个
跟踪
中间件,用
属性侦听操作,并将
属性附加到实际事件,而不是创建这些专门的跟踪事件

然而,令人惊讶的是,我找不到这样使用它的任何真正后果,我很难证明为什么值得努力修复它(有很多这样的跟踪事件,所以这将是一项相当大的工作)

我看到的唯一潜在问题是,在使用devtools时,每当您切换操作时,事件都会被重新发送。不过,我们已经忽略了开发模式下的跟踪操作,所以这不是一个问题


这段代码会导致我不知道的实际问题,还有其他原因吗?

是的,你完全明白了。主要问题是在使用Redux DevTools时进行调试。在先前调度的操作之间来回切换将导致这些操作通过减缩器再次调度,从而重新触发此行为


是的,这类事情的“正确”位置应该是中间件。

我能想象的唯一问题是,如果新开发人员开始使用这种代码库,他们可能会根据api调用的响应实现一些状态更改功能。正如您所指出的,这只是对redux的滥用。中间件将是一个好办法。同意,我想我会添加一些评论“谴责”这个减缩器以防止出现这种情况。谢谢事实上,我很惊讶地听到没有更重要的后果!这是一种代码味道,但我想这是少数几个只会产生学术问题的案例之一。谢谢你的回答。在技术层面上,Redux只需调用根减速器并存储结果。对“纯函数”的关注是开发工具/时间旅行调试的结合,确保适当地进行React Redux更新、可测试性和函数编程概念的通用性。