为什么我们在 Flux/Redux 架构中解耦 action 和 reducer？

Question

我很长一段时间都在先使用 Flux，然后再使用 Redux，我确实喜欢它们，我看到了它们的好处，但我脑海中不断浮现一个问题： p>

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

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

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

• 超级简单
• 将其视为 React 组件的状态接口（setState、this.state），没有渲染部分。

因此，您唯一需要做的就是在我们的 TSC 中的状态发生变化时触发组件的重新渲染以及更改该状态的可能性，在我们的例子中，这将是修改该状态的简单方法：@987654322 @、setError、setLoading等

我所看到的是，actions 和 reducer 是动态或静态代码调度的解耦，所以不是调用myStateContainer.doSomethingAndUpdateState(...)，而是调用actions.doSomethingAndUpdateState(...)，你让整个flux/redux 机器连接那个action到状态的实际修改。整个事情还带来了 thunk、sagas 和其他中间件来处理更复杂的操作的必要性，而不仅仅是使用常规的 javascript 控制流。

主要问题是这种解耦需要您编写很多东西来实现这种解耦： - 动作创建函数的接口（参数） - 动作类型 - 动作有效载荷 - 你的状态的形状 - 你如何更新你的状态

将此与我们的理论状态容器 (TSC) 进行比较： - 你的方法的接口 - 你的状态的形状 - 你如何更新你的状态

那么我在这里错过了什么？这种脱钩有什么好处？

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

让我解释一下为什么这个问题的投票最多的答案既没有回答我的问题，也没有回答原来的问题： - Actions/Reducers 让你问谁和如何？这可以通过我们的 TSC 来完成，它只是一个实现细节，与 action/reducers 本身无关。 - Actions/Reducers 让你回到你的状态：这又是一个状态容器的实现细节问题，可以通过我们的 TSC 来实现。 - 等等：状态变更指令、中间件，以及目前通过 action/reducers 实现的任何东西都可以通过我们的 TSC 来实现，这只是实现它的问题。

非常感谢！ 弗兰

Answer 1

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

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

另一个原因是将代码中的数据流限制在一个方向上。如果我们允许任意不受约束的状态修改，我们可能会得到状态更改，导致更多状态更改导致更多状态更改......这就是为什么在 reducer 中调度操作是一种反模式。我们想知道每个动作的来源，而不是创建级联动作。

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

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

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