Redux - 一对多减速器

Question

我来自Elm-comunity和Elm,每个应用程序都有它的视图,模型和状态,并且基本上采用非常类似的方法,即IMO,以解决REDx的问题.

无论如何,我发现自己正在努力解决多个减速器的问题.在Elm中,我习惯为所有动作(消息)创建单独的文件,为"反应"(视图)创建单独的文件,为状态(模型)创建单独的文件,为所有减少器(更新)创建单独的文件.

更新文件中包含每个可能的操作,更新文件不能通过多个文件传播,将所有逻辑保存在一个位置.

另一方面,Redux鼓励为reducers制作多个单独的文件,然后将它们与combineReducers结合使用,我发现这非常令人困惑,或多或少是一个缺点而不是优势.

如果我把事情做对了,每个减速器只会获得它"负责"的部分并且能够对它做一些事情,并且不同的减速器不能访问其他减速器的其他状态属性/属性.

做这个IMO的缺点:

1. 减速器A的功能可能需要有关减速器B的信息,但由于此原因无法访问.
2. 更多文件会导致更多混乱和无意的错误.
3. 不必要的代码拆分....

拆分代码的优点是什么,或者我没有在这里看到什么？

Answer 1

在Dan Abramov发现这个帖子并写下另一个惊人的答案之前,我会尝试解释:-)

缺点:

减速器A的功能可能需要有关减速器B的信息,但由于此原因无法访问.

这个问题并没有真正发生,因为完全取决于减速器应该如何组合.如果reducer仅对状态树的一部分感兴趣,那么combineReducers将确保它只接收该部分.但是如果它需要更多状态,那么你将以一种接收整个状态的方式应用这个特定的reducer.

整个应用程序最终只有一个reducer - 一个处理整个状态和所有操作 - 但你可能希望在某些时候将你的应用程序代码拆分成与主题相关的模块,所以它更容易编写较小的与主题相关的缩减器,并将它们合并为一个.combineReducers只是一个帮手,让你可以随时方便地做到这一点.

2. 更多文件会导致更多混乱和无意的错误.
3. 不必要的代码拆分....

由您决定何时拆分代码.我喜欢在不同的文件中保留不相关的功能.例如,如果我的网络应用程序有一个聊天模块,我可能会创建一个chat包并将所有与聊天相关的代码放在那里 - 一个视图,一堆操作和理解这些操作的reducer.

继续前进:

combineReducers很有帮助,因为它与可重复使用的应用程序非常有效.例如,我可以编写一个处理注释的模块......其中一部分将是一个减速器,如:

const initialState = {
  commentList: [],  // list of { author, text, upvotes }
  commentingAllowed: true,
}

function commentReducer(state, action) {
  if (typeof state === 'undefined') {
    return initialState;
  }
  switch (action.type) {
    // ...
  }
}

但我的应用程序的实际状态可能更复杂,如:

{
  currentArticle: {
    title: "Some article",
    published: "2017-04-05",
    author: "someone",
    comments: {
      commentList: [],
      commentingAllowed: true,
    }
  }
}

注释状态嵌套在currentArticle,但我的评论应用程序(并且特别commentReducer是不了解文章的整个概念!所以我不希望它接收整个状态 - 它不知道如何处理它.我想要此reducer仅接收与其注释对应的状态部分.

请注意,我可以同时发表很多文章,也可能是其他可评论的内容.通过巧妙地组合reducer,您可以拥有评论应用程序的多个"实例",每个实例只关注其自身的一小部分状态.这需要比combineReducers单独使用更聪明的胶水代码,但它显示了一种情况,当减速器自然只需要应用程序状态的特定部分时 - 关注点分离.