reactjs - 为什么我们在 Flux/Redux 架构中解耦操作和 reducer ？

Question

我已经先使用 Flux，然后使用 Redux 很长一段时间了，我确实喜欢它们，并且看到它们的好处，但有一个问题一直在我脑海中浮现:

为什么我们要解耦actions和reducer，并在表达改变状态意图的调用(action)和改变状态的实际方式(reducer)之间添加额外的间接，这样就更难理解了提供静态或运行时保证和错误检查？为什么不直接使用修改状态的方法或函数呢？

方法或函数将提供静态保证(使用 Typescript 或 Flow)和运行时保证(未找到方法/函数等)，而未处理的操作根本不会引发任何错误(无论是静态错误还是运行时错误)，您将只需要看看预期的行为没有发生。

让我用我们的理论状态容器 (TSC) 更好地举例说明:

• 非常简单
• 将其视为 React 组件的状态接口(interface)(setState、this.state)，没有渲染部分。

因此，您唯一需要的就是当 TSC 中的状态发生变化时触发组件的重新渲染，并且可以更改该状态，在我们的例子中，这将是修改该状态的普通方法:fetchData、setError、setLoading 等

我看到的是，actions 和reducer 是动态或静态代码分派(dispatch)的解耦，因此您不调用 myStateContainer.doSomethingAndUpdateState(...) ，而是调用 actions .doSomethingAndUpdateState(...)，然后让整个 Flux/Redux 机制将该操作连接到状态的实际修改。这整件事还带来了 thunk、sagas 和其他中间件的必要性来处理更复杂的操作，而不是仅仅使用常规的 javascript 控制流。

主要问题是这种解耦需要你编写很多东西来实现解耦:- Action 创建器函数的接口(interface)(参数)- Action 类型- Action 有效负载- 你所在州的形状- 如何更新你的状态

将其与我们的理论状态容器 (TSC) 进行比较:- 你的方法的接口(interface)- 你所在州的形状- 如何更新你的状态

那么我在这里错过了什么？这种解耦有什么好处呢？

这与另一个问题非常相似:Redux actions/reducers vs. directly setting state

让我解释一下为什么该问题得票最多的答案既没有回答我的问题，也没有回答原来的问题: - Actions/Reducers 让您可以提出问题“谁”以及“如何”？这可以通过我们的 TSC 来完成，它只是一个实现细节，与 actions/reducer 本身无关。 - Actions/Reducers 让您及时返回状态:这又是状态容器的实现细节问题，可以通过我们的 TSC 来实现。 - 等等:状态更改命令、中间件以及当前通过 actions/reducer 实现的任何内容都可以通过我们的 TSC 实现，这只是实现它的问题。

非常感谢!弗兰

Answer 1

主要原因之一是通过操作来限制状态更改允许您将所有状态更改视为仅取决于操作和先前的状态，这简化了对每个操作中发生的情况的思考。该架构将与“现实世界”的任何类型的交互“捕获”到 Action 创建器功能中。因此，状态改变可以被视为事务。

在理论状态容器中，状态变化可能随时发生不可预测的情况，并激活各种副作用，这将使它们更难以推理，并且更难发现错误。 Flux 架构强制将状态更改视为离散事务流。

另一个原因是限制代码中的数据流仅在一个方向上发生。如果我们允许任意不受约束的状态修改，我们可能会得到状态更改，从而导致更多的状态更改，从而导致更多的状态更改......这就是为什么在 reducer 中分派(dispatch)操作是一种反模式。我们想知道每个 Action 来自哪里，而不是创建级联 Action 。

Flux 的创建是为了解决 Facebook 的一个问题:当触发某些接口(interface)代码时，可能会导致一连串几乎不可预测的副作用，而这些副作用又会相互影响。 Flux 架构通过使每个状态转换成为事务和单向数据流，使这成为可能。

但是，如果执行此操作所需的样板让您感到困扰，您可能会很高兴知道您的“理论状态容器”或多或少存在，尽管它比您的示例复杂一些。它的名字叫MobX .

顺便说一句，我认为您对整个“这是一个实现细节”的事情有点过于乐观了。我认为，如果您尝试为理论状态容器实际实现时间旅行调试，那么您最终得到的结果实际上与 Redux 非常相似。