Redux - 一对多减速器 [英] Redux - One vs Multiple reducers
问题描述
我来自Elm-comunity和Elm，每个应用程序都有它的视图，模型和状态，并且基本上采用非常类似的方法，IMO，以解决REDx的问题。
I come from the Elm-comunity and in Elm, every application has its view, its model and its state and basically takes very similar approach, IMO, to solving problems as redux does.
无论如何，我发现自己正在努力解决多个减速器的问题。在Elm中，我习惯为所有动作（消息）创建单独的文件，为反应（视图）创建单独的文件，为状态（模型）创建单独的文件，为所有减少器（更新）创建单独的文件。
Anyway, I found myself struggling with the idea of multiple reducers. In Elm I am used to make a separate file for all the actions (Messages), a separate file for "react" (View), a separate one for state (Model), and a separate one for all the reducers (Update).
更新文件中包含了所有可能的操作，更新文件无法通过多个文件传播，将所有逻辑保存在一个位置。
Every possible action gets covered inside Update file and Update file cannot be spread trough multiple files, keeping all the logic in one place.
另一方面，Redux鼓励为Reducer制作多个单独的文件，然后将它们与combineReducers结合使用，我发现这非常令人困惑，或多或少是一个缺点而不是优势。
On the other hand, Redux encourages making multiple separate files for reducers and later on combining them with combineReducers, which I found very confusing and more or less a disadvantage rather than an advantage.
如果我把事情做对了，每个减速器只能获得它负责的部分，并且能够对它做一些事情，不同的减速器不能访问其他减速器的其他状态属性/属性。
If I get things right, each reducers only gets the part it's "responsible" for and is able to do something with it and different reducers cannot access other state-properties/properties of other reducers.
执行此IMO的缺点：
- reducer A的功能可能需要有关信息的信息来自reducer B，但因此无法访问。
- 更多文件会导致更多混乱和无意的错误。
- 不必要的代码拆分。
...
拆分代码的优点是什么，或者我在这里看不到什么？
What are the pros of splitting code or am I not seeing something here?
推荐答案
在Dan Abramov发现这个帖子并写下另一个惊人的答案之前，我会尝试解释： - ）
I'll attempt to explain before Dan Abramov spots this thread and writes another amazing answer :-)
缺点：
减速器A的功能可能需要有关减速器B的信息，但由于此原因无法访问。
Function from reducer A may need info about information from reducer B, but cannot be accessed because of this.
这个问题并没有真正发生，因为完全取决于你应该如何组合减速器。如果reducer只对状态树的一部分感兴趣，那么 combineReducers 将确保它只接收该部分。但是如果它需要更多状态，那么你将以一种接收整个状态的方式应用这个特定的reducer。
This problem doesn't really happen, because it's completely up to you how the reducers should be combined. If a reducer is interested in only a part of the state tree, then combineReducers would make sure it only receives that part. But if it needs more state, then you'd apply this particular reducer in a way that it receives the whole state.
整个应用程序只有一个reducer最后 - 一个处理整个状态和所有操作的东西 - 但是你可能希望在某些时候将你的应用程序代码拆分成与主题相关的模块，因此编写较小的与主题相关的简化器并将它们组合起来更容易合而为一。 combineReducers 只是一个帮助你可以在你想要的时候方便地做到这一点。
The whole application is going to have only one reducer in the end - one that handles the whole state and all the actions - but you'll probably want to split up your application code into topic-related modules at some point, so it's easier to write smaller topic-related reducers and them combine them into one. combineReducers is just a helper that lets you do that conveniently when you want to.
- 更多文件会导致更多混乱和无意的错误。
- 不必要的代码拆分。 ...
由您决定何时拆分代码。我喜欢在不同的文件中保留不相关的功能。例如，如果我的网络应用程序有一个聊天模块，我可能会创建一个聊天包并将所有与聊天相关的代码放在那里 - 一个视图，一堆操作和理解这些行为的减速器。
Up to you when to split your code. I like to keep unrelated functionality in different files. For example if my web app has a chat module, I'll probably make a chat package and put all chat-related code in there - a view, a bunch of actions and the reducer that understands these actions.
继续前行：
combineReducers 非常有用，因为它可以与可重复使用的应用程序配合使用。例如，我可以编写一个处理注释的模块......其中一部分将是一个减速器，如：
combineReducers is helpful because it works really well with re-usable apps. For instance I can write a module that deals with comments... Part of it will be a reducer like:
const initialState = {
commentList: [], // list of { author, text, upvotes }
commentingAllowed: true,
}
function commentReducer(state, action) {
if (typeof state === 'undefined') {
return initialState;
}
switch (action.type) {
// ...
}
}
但我的申请的实际状态可能更复杂，例如：
but the actual state of my application can be more complex, like:
{
currentArticle: {
title: "Some article",
published: "2017-04-05",
author: "someone",
comments: {
commentList: [],
commentingAllowed: true,
}
}
}
评论状态嵌套在 currentArticle 下，但是我的评论应用（特别是 commentReducer 不知道文章的整个概念！所以我不希望它接收整个状态 - 它不知道如何处理它。我希望这个reducer只接收部分的状态与其评论相对应。
The comment state is nested under currentArticle, but my comments app (and specifically commentReducer is not aware about the whole concept of articles! So I don't want it to receive the whole state - it wouldn't know what to do with it. I want this reducer to only receive the part of the state that corresponds to its comments.
请注意，我可以同时发表很多文章，也可能是其他可评论的内容。通过巧妙地结合使用reducer，您可以拥有多个实例 的评论应用程序，每个只关注自己的一点点状态。这需要比 combineReducers 单独更聪明的胶水代码，但它显示了一种情况，当减速器自然只需要应用程序状态的特定部分时 - 分离关注。
Note that I could have many articles at once, also maybe other commentable things. With clever combining of reducers, you could have multiple "instances" of the comments app, each only taking care of its own small bit of state. This requires a bit smarter glue code than combineReducers alone, but it shows the kind of situation when it's natural for a reducer to only want a specific part of the application state - separation of concerns.
这篇关于Redux - 一对多减速器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
