首页 文章

为什么我们在Flux / Redux架构中解耦动作和缩减器?

提问于
浏览
5

我一直在使用Flux和Redux以后很长一段时间,我确实喜欢它们,我看到了它们的好处,但是我脑海中浮现的一个问题是:

为什么我们将动作和减少器分离并在表示改变状态(动作)的意图的调用和改变状态(减速器)的实际方式之间添加额外的间接,以这种方式更难以提供静态或运行时保证和错误检查?为什么不使用修改状态的方法或函数?

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

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

  • 这很简单

  • 将其视为React Component的状态接口(setState,this.state),不带渲染部分 .

因此,您唯一需要的是在TSC中的状态发生变化时触发组件的重新渲染以及更改该状态的可能性,在我们的示例中将是修改该状态的普通方法: fetchDatasetErrorsetLoading

我看到的是动作和减速器是动态或静态调度代码的分离,所以不是调用 myStateContainer.doSomethingAndUpdateState(...) 而是调用 actions.doSomethingAndUpdateState(...) ,而你让整个flux / redux机器将该动作连接到状态的实际修改 . 这一切也带来了thunk,sagas和其他中间件处理更复杂动作的必要性,而不是仅使用常规的javascript控制流 .

主要的问题是,这种解耦需要你编写很多东西才能实现解耦: - 动作创建者函数的接口(参数) - 动作类型 - 动作有效负载 - 你的状态的形状 - 你如何更新你的状态

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

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

这与其他问题非常相似:Redux actions/reducers vs. directly setting state

让我解释为什么对这个问题的最多投票答案不能回答我或原来的问题: - 行动/减少者让你问问谁和如何?这可以通过我们的TSC完成,它只是一个实现细节,与动作/减速器本身无关 . - 动作/减少器让你回到你的状态:再次这是状态容器的实现细节问题,可以通过我们的TSC实现 . - 等等:状态变更单,中间件以及当前通过操作/减速器实现的任何事情都可以通过我们的TSC来实现,这只是它的实现问题 .

非常感谢!弗兰

1 回答

  • 2

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

    在你的理论状态容器中,状态变化可能在任何时候都不可预测地发生并激活各种副作用,这会使它们更难以推理,并且更难找到错误 . Flux架构强制将状态更改视为离散事务流 .

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

    创建Flux是为了解决Facebook上的一个问题:当某些界面代码被触发时,这可能会导致一系列几乎不可预测的副作用,每个副作用都互相造成 . Flux架构通过使每个状态转换成为事务和数据流单向来实现这一点 .

    但是,如果为了做到这一点而需要的样板需要你,你可能会很高兴知道你的"Theoretical State Container"或多或少存在,尽管's a bit more complicated than your example. It'被称为MobX .

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

相关问题