根据我的理解,redux是严格的单向数据流。
actions (data in) -> store updates (reducer) -> react render (data flow ends here)
在可观察到动作的情况下,它仍然是单向的
actions -> state changes -> react render
^ |
| |
epics<-
但是,在状态可观察的情况下,数据会回流
actions -> state changes -> react render
^ |
| |
epics <----
因此,在以下情况下,它可能会导致无限的数据流
epicA
订阅了stateA
更改stateB
和epicB
订阅了stateB
更改stateA
。
尤其是当应用增长时,监视状态更改和调试变得越来越困难,这正是单向数据流试图解决的问题。
我在任何地方有什么误解吗?
为了澄清我的问题,调度具有状态的操作不是可观察到的 redux 单向数据流的反模式吗?
No. "单向数据流"的主要思想是,应用程序的随机其他部分不能(或不允许(更改这些数据本身。 相反,拥有该数据的应用程序的一部分负责所有更改,无论是 Redux 存储还是有状态的 React 组件。
在您描述的特定示例中,所有状态更新仍由调度到 Redux 存储的操作引起,并且任何状态更新都可以追溯到提供更新状态的调度操作和化简器函数。
现在,是的,复杂的异步逻辑可能会变得纠结,但这是一个与"单向数据流"概念不同的问题。