纯减速器没有副作用，并且可以实现时间旅行。它们使对应用程序行为的推理更容易。
这对我来说很直观。但我无法清楚说明为什么纯 reducer 会导致这些积极的非功能属性。
有人能帮我解释一下为什么让 reducer 无副作用可以更容易地推理应用程序行为吗？
是因为在运行 reducer 后保证您具有完全相同的状态吗？
如果是这样，那么即使是有副作用的（即非纯的）reducer 也肯定有这个属性吗？
问问题
4380 次
2 回答
14
是因为在运行 reducer 后保证您具有完全相同的状态吗？
是的，纯reducer 是确定性的，这意味着如果给定相同的输入，它们将始终产生相同的结果输出。此属性有助于单元测试等情况，因为您知道如果测试通过一次，它将始终通过。
如果是这样，那么即使是有副作用的（即非纯的）reducer 也肯定有这个属性吗？
不，不纯的 reducer 将依赖于输入和应用程序的状态。在您进行测试时，它们可以以给定的方式运行 1000 次，但是当您的应用程序碰巧处于您从未想过要测试的特定状态时，它们就会中断。
当然，完全有可能在单元测试中出现漏掉极端情况的空白。但是，如果测试的结果是 100% 基于输入的，那么仅通过查看 reducer 预期的指定输入，您就更有可能注意到这些极端情况。
如果一个函数改变了应用程序的状态，那么两次运行相同的函数，或者以不同的顺序运行相同的几个函数，可能会导致完全不同的行为。这使得很难推断应用程序的正确性，因为为了知道给定的代码行是否正确，您必须知道在调用它之前发生了什么，可能在应用程序的完全不同的部分。
于 2017-06-26T19:26:16.870 回答
2
是因为在运行 reducer 后保证您具有完全相同的状态吗？
是的，这就是使纯减速器成为“黄金标准”的原因。如果输出只依赖于输入，那么测试、回放、保存历史等就很容易了……
如果是这样，那么即使是有副作用的（即非纯的）reducer 也肯定有这个属性吗？
（不是流行的答案）。这也是正确的。如果您小心的话，非纯减速器也可能具有这些相同的属性。但是，它更容易出错，并且（从概念上）没有多大意义。（我认为）你得到的想法是一切都只是输入和输出。您可以稍微改变一下思路，将“非纯”减速器的内部状态视为减速器的另一个输入。
从这个意义上说，您可以想象跟踪您的应用程序状态、您的操作和减速器的内部状态，并最终获得与纯减速器相同的播放等属性（尽管您需要更多代码来处理那）。
然而，问题来了：现在您有了实际的应用程序状态和减速器的内部（和隐藏）状态。谁想跟踪两组状态？这才是真正使测试、推理和实施更加困难的原因。有更多“种类”的事情需要跟踪，并且更容易错过/忘记关键细节。本质上，如果您的应用程序已经有很大一部分专门用于跟踪状态，为什么还要在reducer 中隐藏更多状态？
因此，即使为了“正确性”而忽略做正确的事情，从概念上讲，对于您的整个系统架构而言，将所有状态都保存在一个地方在概念上更简单。
于 2017-06-26T19:36:58.947 回答