javascript - Redux-一台vs多台异径管

我来自Elm社区，在Elm，每个应用程序都有其 View ，其模型和状态，并且基本上像uxux一样采用非常相似的方法IMO(IMO)来解决问题。

无论如何，我发现自己在努力应对多个异径管的想法。在Elm中，我用于为所有操作(消息)创建一个单独的文件，为“ react ”( View )创建一个单独的文件，为状态(模型)创建一个单独的文件，并为所有化简器创建一个单独的文件(更新)。

Update文件中包含所有可能的操作，并且Update文件不能通过多个文件传播，从而将所有逻辑都放在一个位置。

另一方面，Redux鼓励为 reducer 创建多个单独的文件，然后再将它们与CombineReducers结合使用，我发现这非常令人困惑，并且或多或少是一个缺点，而不是一个优点。

如果我做对了，每个异化器只能得到它“负责”的部分，并且能够对此做些事情，并且不同的异化器无法访问其他异化器的其他状态/属性。

执行此IMO的缺点:

来自reducer A的函数可能需要有关来自reducer B的信息的信息，但由于此原因而无法访问。

更多文件会导致更多困惑和意外错误。

不必要的代码拆分。
...

拆分代码的优点是什么？我在这里看不到什么吗？

最佳答案

在丹·阿布拉莫夫(Dan Abramov)发现该线程并写出另一个惊人的答案之前，我将尝试进行解释:-)

缺点:



这个问题并没有真正发生，因为完全取决于您如何组合 reducer 。如果reducer只对状态树的一部分感兴趣，则combineReducers将确保它仅接收该部分。但是，如果需要更多状态，则可以以接收整个状态的方式应用此特定的reducer。

整个应用程序最终将只具有一个化简器-一个处理整个状态和所有 Action 的化简器-但您可能会希望在某个时候将应用程序代码拆分为与主题相关的模块，因此更容易实现编写与主题相关的较小的简化器，然后将它们组合为一个。 combineReducers只是一个帮助程序，可让您在需要时方便地进行操作。



由您决定何时拆分代码。我喜欢将不相关的功能保留在不同的文件中。例如，如果我的Web应用程序具有聊天模块，则我可能会制作一个chat包，并将所有与聊天相关的代码放入其中-一个 View ，一堆 Action 以及可理解这些 Action 的reducer。

转向专业人士:
combineReducers很有帮助，因为它与可重复使用的应用程序非常兼容。例如，我可以编写一个处理注释的模块...其中的一部分将是一个reducer，例如:

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不了解文章的整个概念!所以我不希望它接收整个状态-它不知道如何处理它。我希望这个化简仅接收与其注释相对应的状态部分。

请注意，我一次可以写很多文章，也可能有其他可评论的内容。通过精简地组合化简，您可以在注释应用程序中拥有多个“实例”，每个实例仅处理自己的少量状态。这需要比单独的combineReducers更加智能的粘合代码，但是它显示了一种情况，当还原器很自然地只希望应用程序状态的特定部分时-关注点分离。