关于 Redux 数据流的问题。
让我们谈谈巨大的企业价格应用。数十个模块，复杂的化简器层次结构，数百种操作类型。 简单流程： 控件调度操作(例如，输入 - 键入(。这个动作会经过每个减速器，经过数百个开关情况，并且以最小的变化从所有减速器合并新的状态。我认为，在这种情况下，我们有巨大的不必要的开销。
我们可以使用哪些选项来减少开销？
-
将隔离的高级子应用与其自己的提供程序一起使用。 此选项将减少开销。但是，如果我们需要子应用程序中的任何常见功能，例如帐户信息/通知/等，我们应该复制它。
-
使用异步化简器进行代码拆分。 此选项也会减少开销，但不建议这样做。
-
制作带有动作过滤器的减速器。在这种情况下，我们向每个操作添加附加信息，哪个化简器应该处理它。 此选项还减少了新状态合并的中断次数和复杂性。
-
但是在选项 3 中，我无法理解一件事。
- 我们有控制权，它与国家的具体部分相连。
- 99%的动作由单个减速器处理。
- 化简器上的每个动作都由"case函数"处理，该函数被移动到单独的逻辑模块。
- 我们有动作创建者，它知道处理这个动作的具体化简器，并可以访问全局状态。
为什么行动创造者应该调度全局行动，然后由级联的化简器过滤，然后通过数十个案例进行切换，而不是新全局状态的最佳合并？ 为什么我们不能在action-creator中调用case-function，以最佳方式计算新的全局状态并将其作为具有"SET_GLOBAL_STATE"操作类型的有效负载进行调度？
我知道这是反模式的。但我无法理解在这种情况下我们失去了什么。 如果有人能解释我出了什么问题，我会很高兴的。
这里有几个想法。
首先，根据 Redux FAQ 中关于在操作创建者和化简器之间拆分逻辑的条目，将大部分逻辑放在哪里取决于您。 如果您希望在动作创建器中对新状态的一部分进行实际计算，并且只需让给定的切片缩减器执行return {...state, ...action.payload}，则可以。
其次，根据 Redux FAQ 中关于调用化简器函数性能的条目，调用许多化简器函数的成本通常非常小，因为它们中的大多数只会检查操作类型并返回其现有的状态片。 因此，减速器逻辑很少会成为性能瓶颈。
第三：是的，完全可以在操作创建器中计算整个新应用状态，并具有单个通用"SET_GLOBAL_STATE"操作。 这将允许使用 Redux 的中间件和时间旅行调试等。 但是，这也抛弃了Redux的许多可能的好处和用例。 我在我的博客文章 Redux 的 Tao 1 - 实现和意图和 The Tao of Redux， Part 2 - 实践和哲学中讨论了 Redux 的很多预期目的。
总结一下我们不鼓励您描述的想法的原因：Redux 旨在让您轻松跟踪某个状态的更新时间、原因和方式。 虽然由您决定您希望操作的粒度，但理想情况下，它们应该具有语义意义。 这样，当您阅读操作历史记录日志时，您实际上可以了解已调度的操作的顺序。 此外，如果搜索给定的操作类型，则应该能够快速缩小该操作在代码库中使用该操作的确切位置。 如果只有一个"SET_GLOBAL_STATE"操作，则几乎不可能确定代码的哪一部分导致了给定的状态更新。