Redux是可预测的状态容器

Question

Redux项目的描述是：

  

Redux是可预测的状态容器

在这种情况下可以向我解释什么是“可预测”的意思？

Answer 1

您首先必须了解Redux的工作方式。关键原则很少：

1. 状态是不可变的对象
2. 您永远不会改变应用程序状态，总是返回一个经过修改的新状态
3. 所有状态更改都是通过操作启动的（它们包含所需的更改详细信息）
4. 减速器采取当前状态，采取行动并产生新状态（(state, action) => state）

所以您可以看到这都是单向的（更改仅以一种方式流动）：

状态->动作->减速器->状态->动作->减速器->状态...

Redux在很大程度上受到Elm架构的启发，并鼓励函数式编程原理，其中之一是纯函数（它们不会产生副作用（例如http调用，磁盘读取），并且对于相同的输入它们的输出始终是相同的）。 / p>

Reducer中的每个单一状态更改都必须由开发人员明确处理。而且所有的减速器都应该是纯净的。那就是可预测性的来源。

总而言之，在这种情况下 predictable 意味着，使用Redux，您将知道应用程序中的每个动作将执行什么操作以及状态将如何改变。

Answer 2

一段时间后，我明白了这一点： 首先，我的问题来自C ++ / Java / C＃事件驱动（Redux不仅针对JS实现）。

因此，我想知道像Winform之类的旧模式时尚事件驱动环境有什么坏处吗？它们都与DataTable或普通类（结构）的集合一起使用。可视组件的状态为“编辑”状态或其他“小部件”状态，但没有逻辑。 （我在这里不是指诸如 MVC 或 MVVW 之类的大字眼，也不是所有其他口号。但所有人都说出了同样的道理：我们必须在某些方面将逻辑视图与逻辑分开方式）。

请参阅 Evaldas Buinauskas 答案，有4条原则。让我解释一下为什么这些原则不是重点：

1>由于什么原因我需要不可变的？ （可以通过面向方面的编程来实现自动更改意识，或者甚至不至于每次操作后都手动调用重新渲染）

2>与上述相同（我仍然猜想我们不希望在不删除前一个动作的情况下为每个动作克隆孔存储。对于大多数应用程序来说，由于RAM的限制，没有必要或不可能）。

3>我知道所有事件驱动的实现。

4>以上内容。使用所有已知的事件驱动器模式，Action的结果是不变且不必要的，并且新状态可以很好地实现。

所以，我认为 Evaldas Buinauskas 的主要答案是：

  

Redux在很大程度上受到Elm架构的启发，并鼓励函数式编程原理，其中之一是纯函数（它们不会产生副作用（例如http调用，磁盘读取），并且对于相同的输入它们的输出始终是相同的）。 / p>

使用不更改Store之外任何内容的纯函数，我们可以获得更清晰和可测试的代码（我想这是“谓词”的意思）。

Answer 3

Redux是一个“状态容器”，因为它保存了应用程序的所有状态。它不能让您直接更改状态，而是迫使您将更改描述为称为“动作”的简单对象。可以记录动作并在以后重播，因此这使状态管理可预测。以相同的顺序执行相同的操作，您将最终处于相同的状态。

通过 丹·阿布拉莫夫

Answer 4

您需要了解 Reux 中是如何进行更改的，以及其中的 action 和 reducer 是什么。

• 动作是一个具有类型属性的对象，它描述了应用程序状态的变化。
• reducer 实际上根据操作执行状态转换。

通过这种方式，reducer 根据多个可能动作中的一个确定动作执行确定的状态转换。因此，每次特定操作导致状态发生特定变化并使 Redux 可预测时。