Reactjs redux 可以被视为 pubsub 或观察者模式吗

Redux不应该"取代react.js的最初 idea "，而是更像一个库，用于管理组件之间的共享状态，并协调状态变化.

该代码除了订阅存储发出的更改外，还执行一些优化，例如仅在真正需要时才向组件传递新props (从而触发重新渲染).

还可以考虑将组件内部状态与Redux一起使用是非常好的.您可以使用内部状态存储不需要/不想与其他组件共享的状态.

当你有一个更复杂的应用程序时，你会看到像Redux这样的东西的需要，顶级组件需要相互通信(操作)，并以某种方式共享一些状态.

Redux中的操作在默认情况下只是POJO(普通的旧javascript对象)，您可以将它们视为"事件"，您经常发送这些事件以响应用户触发的操作(例如，用户单击按钮)，但您不限于此，您可以从任何地方发送操作.Redux存储监听这些操作，并调用传递您调度的操作对象的简化程序(纯函数).

拦截器可以管理所有已调度操作的状态，并返回已调度操作的状态.

从这个意义上讲，reducer是一个处理操作并根据需要更新状态的函数.

反过来，当reducer通过返回状态的新副本来更新状态时，连接的组件(订阅了状态中的更改)将被传递新的props ，并将重新渲染以反映更改.

有时候，仅仅分派普通的js对象是不够的，您需要更多的控制.当您需要执行更复杂的逻辑时，这一点就很清楚了，例如，当您需要根据AJAX调用的响应更新状态中的计数器时.

通过redux thunk，您可以分派函数，而不仅仅是普通对象.通过分派一个函数，您可以用一种非常简单的方式有效地实现控制模式的反转.您的操作将成为函数描述的"配方"，而不仅仅是POJO操作中的简单语句.

为什么POJOs支持"开箱即用"，对于动作，为什么没有一个基本动作类或其他什么？主要是因为没有必要这么做.一个简单的对象(基本上被认为是值包)和一个type属性是你真正需要的，它基本上是最简单的接口.您可以认为这是针对接口(动作)的编程，而不是实现.

为什么全局状态更好，而不是每个组件管理自己的状态？主要是因为管理状态实际上是一个不平凡的js应用程序中最难的部分.通过使用Redux，您可以从UI层提取所有逻辑，从而使其更易于测试.事实上，理想情况下，您应该能够测试Redux应用程序的所有真实"业务逻辑"，而无需渲染单个组件.

组件变得"更蠢"和"更纯"，因为它们只是呈现它们被要求做的事情.这里的"Purer"指的是，因为它们不包含任何状态，所以呈现的内容只取决于任何给定时间点的输入(阅读"props")，而不是任何历史，因此是"无状态的".

将状态作为一个可序列化的json对象，还可以方便地进行调试、快照和从服务器或本地存储发送/恢复.