Redux解决什么问题？
在设计Workstation时，想解决当前意大利面条式的任务状态管理代码，隐隐觉得可以通过Redux的Unidirectional Data Flow概念来解决。但动手写设计思路时却感觉无法说服自己为什么要引入这样的概念。
究其原因，是自己尚不能清晰地、自信地回答为什么需要Redux，即Redux解决了什么问题。所以停下手上工作，先去寻找答案。
Google了大半天，看了包括官方文档、StackOverflow、Medium等各种资料，最终觉得还是《What Does Redux Do? (and when should you use it?)》这篇介绍得最贴切：
几乎所有关于Redux的文章（包括Redux首页），都在强调Redux是可预测的状态容器（Predictable State Container），因此他们都会重点介绍Redux如何做状态管理。但我很困惑，React不是已经有状态管理机制了吗（setState），并且一个状态对应一种页面渲染结果就是React提出的，搞得好像没有Redux之前，React就没有状态管理一样。在这篇文章里，也表达了相同的观点：Redux虽然让状态管理变得更好，但Redux的解决的问题并不是状态管理。
Redux真正解决的是数据流的问题：跨层级传递数据。解法是将数据的管理独立出来，统一由Store完成，实现将任何数据插入任何组件（Plug Any Data into Any Component）的功能。
Redux的机制其实和Excel的formula很像！假如A3=A1+A2，当A1或A2发生变化时，就自动触发依赖的公式重新计算，也是一种按需计算的方式。
类比到Workstation，Workstation与传统的任务流程引擎的差异正式层级立体结构的任务体系，任务的状态或上下文数据需要在不同层级的流程间共享，因此Redux的理念是正好适合这样的复杂场景。