为什么 Redux 需要 Actions 和 Reducers？

Question

我试图理解为什么Redux 是这样设计的。例如，假设我有一个包含待办事项列表的商店。

如果商店实际上是这样的对象：

{1: todo1,
 2: todo2,
 3: todo3, ...}*

我们将它封装在一个类中，让我们可以执行以下操作：

todoStore.getAll()
todoStore.add(todo)
todoStore.get(id);
todoStore.get([1,2,3,...]);
todoStore.filter((todo)=> todo.id == 1);
todoStore.del(1);
todoStore.update(2, {title: 'new title'}:Partial<Todo>);
....

因此，在这种情况下，我们只有一个 Todo 模型和一个 TodoStore，它们的 API 允许我们查询/过滤、删除、更新和添加项目。

为什么 Redux 需要 Actions 和 Reducers？

其中一个答案表明：

相反，Redux 使用一种模式，当给定状态和动作时，总是会产生相同的新状态。

因此，由于这种模式，我们似乎需要 action 和 reducer，但对我来说，这些看起来像是内部实现细节。为什么TodoStore 不能在内部实现这些？

例如，如果我们在缓存中有 1 个 todo 实例，然后我们添加了另一个，我们现在有 2 个。这似乎是一个非常简单的实现......但我一定错过了一些东西......

背景

我正在考虑实现类似的东西

@TodoStore
class Todo {

}

注释/装饰器将生成商店，然后客户将通过以下方式获取商店：

todoStore:TodoStore = StoreCache.get(Todo);
todos:Observable<Todo[]> = todoStore.getAll();
...

等等。看起来它可能就是这么简单......所以只是想知道 Redux 提供了什么，这可能会丢失......换句话说，为什么 redux 决定它需要动作和减速器而不是简单的Store<Type> 之类的接口？

另一种看待它的方式是，Reducers 和 Actions 是否添加了 Store<Type> 接口无法通过实现方式/语言限制添加的内容？

断言

• 操作是方法名称与实体名称的组合。因此，例如，如果我们有 Store<Todo>（一种对 todo 类型进行操作的 Store 类型），并说一个更新方法，例如 update(id:String, todo:Todo)，那么我们实际上拥有的 Action 名称将是 TODO UPDATE强>。如果第二个参数是复数，即update(id:String, todos:Todo[])，那么操作是TODO UPDATES ...

• 如果我们正在进行更新，我们必须找到我们正在更新的实例并更新它们，我们通常使用 ID 来执行此操作。一旦更新完成，我们可以在不可变状态树中跟踪它们，如果我们希望做一些事情，例如，整个更改可以包装在命令对象实例中，以便我们可以撤消/重放它。我相信 Ecipe EMF 框架 API 有一个很好的模型，可以通过 Elipse 撤消/重做功能为生成的模型实现这一点。

Answer 1

这个问题似乎有点宽泛或基于观点，但我会试一试。

Redux 存储是不可变的，因此你不能改变存储。相反，Redux 使用一种模式，当给定一个状态和动作时，总是会产生相同的新状态。操作就是这样，告诉存储要执行什么操作，reducers 执行该更改并返回一个新状态。

如果您来自可变的面向对象背景，这可能会让人觉得奇怪，但它允许您浏览状态更改、返回历史和重播操作等。这是一种强大的模式。

Answer 2

这对于评论来说太长了，可能是一个答案，但它更多的是关于 Redux 存在的概念，而不是它的实现的细节。

考虑看似简单的赋值语句：

var foo = {bar: 1};
foo.bar = 3;

简单吧？除了...如果我需要foo.bar 的先前值怎么办？如果我需要存储对状态转换本身的引用，以便我可以例如重玩吗？语句不是 JavaScript 中的一等实体：

var transition = foo.bar = 3;

没有真正的意义。您可以将其包装在 lambda 表达式中：

var transition = () => { foo.bar = 3 };

但这无法捕获转换语义，只需将foo.bar 的状态设置为 3。如果前一个状态对下一个状态很重要怎么办？你如何分享foo？把它塞进一个全局，希望没有人在你身上变异？但是如果foo 在它的状态变化周围有清晰的语义并且在其他方​​面是不可变的，那么......

其中有一些有用的属性：

1. 代码重新加载。如果您的所有状态更改都是一流的，您可以重新加载您的代码，然后只需重放它们即可恢复到您所处的状态。
2. 在服务器上进行复制。如果生产错误丢弃了创建它们的状态转换怎么办？是否曾经无法重现错误？过去的事情。
3. 撤消很简单。

还有其他的，但你明白了。现在，您可能不需要所有这些，并且可能不值得失去灵活性（以及 Redux would agree 的作者 Dan Abramov）。但是，通过在系统中为状态转换提供一流的状态可以获得很多好处。