前端框架实现了数据驱动视图的功能。我们使用模板或JSX来描述数据和视图之间的绑定关系，然后只需要关心数据管理即可。
数据是在组件和组件，组件和全球商店之间传输的，称为前端框架的数据流。
一般来说，除了状态数据的某些部分，只有某个组件关心，我们将在组件之外放置状态数据，业务数据和状态数据将在存储中放置。该组件从该组件中获取存储，并在交互时通知商店以更改相应的数据。
该商店不一定是第三方库，例如Redux和Mobox。实际上，在React的上下文中也可以用作商店。但是，上下文作为商店存在问题。任何组件都可以从上下文中获取数据来修改它。然后在检查问题时
正是由于这个原因，我们几乎看不到将上下文用作商店，并且它们基本上与Redux配对。
那么为什么redux是好的？第一个原因是数据流很清楚并且数据统一。
这些组件都是通过调度的动作触发了商店的修改，并且修改后的逻辑位于还原器中。组件将收听存储的数据更改，并从中获取最新数据。
该数据流是一条通道，清晰且易于管理的。
这就是为什么我们必须批准公司中任何许可的批准流，而不是直接寻找某人的原因。集中式管理流程是清晰的，可以追溯到。
在许多情况下，更改存储数据是一个异步过程，例如等待网络请求返回数据，及时更改数据，等待事件更改数据等。这些异步过程的代码是什么？
成分？
可以将其放入组件中，但是如何在异步过程中重复该组件？如何在多个异步过程之间进行串行和并行控制？
因此，当有许多异步过程，并且异步过程和异步过程并非独立时，存在串行，平行甚至更复杂的关系，并且在组件中不可能进行异步逻辑。
我应该把它放在零件中？
Redux提供的中间件机制可以用于放置这些异步过程吗？
首先查看什么是Redux中间件：
REDUX的过程非常简单，即存储的操作，是处理该操作的还原器。因此，如果您想在到达商店之前进行更多处理？在哪里添加？
改革调度！中间件的原则是打包调度层。
以下是ApplyMiddleware的源代码。您可以看到，ApplyMiddleware是商店中的包装层。DisPatch，最终在修改调度后返回商店。
因此，中间件返回的最终功能是处理派遣行动：
中间软件将被包装，并将调度传递到存储中，因此中间件可以自然获得动作，存储和打包的调度，这是接下来的。
例如，Redux-Thunk中间件的实现：
它判断如果操作是一个函数，它将执行函数并通过store.dispath和store.getState，否则将传递给内部使用。
通过redux-thunk中间件，我们可以以函数的形式将异步过程放在调度参数中：
但是，这解决了控制组件中异步过程的问题，该过程是多种异步过程之间并行控制和序列化之间不正确控制的问题吗？
不，此逻辑仍然写在组件中，但是它已移至调度，而没有提供多个异步过程的管理机制。
要解决此问题，您需要使用Redux-Saga或Redux-observable中间件。
Redux-Saga不会改变动作。它将传输动作以存储，但添加了其他异步过程。
启用了Redux-Saga中间件：
致电Run and Run Saga的Watcher Saga：
Watcher Saga听了一些动作，然后打电话给Worker Saga处理：
Redux-Saga将首先通过操作来存储，然后确定是否在时间聆听该动作：
当您发现操作被聆听时，然后执行相应的时间并致电工人传奇以处理：
例如，登录和注销将有不同的工人。
登录将询问登录接口，然后触发登录功能或loginError的动作。
注销会触发注销核能的动作。
Redux Saga的异步过程管理是：首先将操作传输到商店，然后确定是否聆听操作。如果是这样，请致电相应的工人传奇进行处理。
除了Redux传奇的动作过程外，Redux传奇还增加了监视动作的异步过程。
实际上，整个过程更容易理解。理解是发电机的写作更高的：
例如，以下代码：
这意味着对每个监视XXX_ACTION的处理相同，这等同于采用：
但是由于有一段时间，许多学生不了解。这不是死周期吗？
编号后，执行发电机后，它将返回一个迭代器，该迭代器需要另一个程序来调用下一个继续执行的方法。因此，如何执行和继续执行执行。
在Redux-Saga中，工人传奇执行的程序称为任务。WorkerSaga刚刚告诉任务该怎么做，通过呼叫，叉子，fork，put命令（这些命令称为效果）。
然后，任务调用不同的实现功能以执行Worker Saga。
为什么要设计这个？只需直接执行它，为什么需要拆卸这两个部分：Worker Saga和Task。理解成本不高吗？
的确，设计形式作为生成器将增加理解成本，但要换取可检验性。由于各种副作用，例如网络请求，存储的调度措施等，它们都变成了诸如呼叫的效果，例如放置并由某些任务控制。
Redux Saga设计的发电机的形式是学习成本和可检验性的平衡。
还记得redux-thunk的问题吗？无法处理多个异步过程之间并行和串行复杂性的复杂性。Redux-Saga如何解决？
Redux-Saga提供了诸如All，Race，Actee，Takelatest之类的效果，以指定多个异步过程之间的关系：
例如，毫无疑问，将对多个动作进行相同的处理。Takelateest将处理多个动作的最后一个。种族只会返回最快的异步过程的结果，依此类推。
控制多个异步过程之间关系的这些效果正是Redux-thunk所无法获得的，它也是复杂异步过程管理中必不可少的一部分。
因此，Redux-Saga可以对复杂的异步过程进行管理，并具有良好的测试性。
实际上，异步过程的管理最多是RXJS，并且Redux-Observable基于RXJ。这也是复杂的异步过程管理解决方案。
Redux-Observable与Redux-Saga特别相似，例如插件的一部分：
Redux传奇的启动过程是相同的，但并不称为传奇和史诗。
但是，Redux Saga处理异步过程本身，Redux-Observable使用RXJS的操作员：
通过type指定监视操作，然后返回将其传递给商店的操作。
与Redux-Saga相比，由Redux-Observable支持的异步过程更为丰富，并且直接连接了操作员的生态，该过程是开放的，Redux-Saga仅提供几种内置效果来处理过程。
因此，当进行特别复杂的异步过程处理时，Redux-Observable可以使用RXJS操作符号的优势更为明显。
但是，redux-saga的优点是基于发电机的良好可检验性，在大多数情况下，Redux-Saga提供的异步过程的处理能力足够，因此相对而言，Redux-Saga使用更多的使用更多用途。
前端框架实现了数据的绑定要查看，我们只需要关心数据流即可。
与上下文的混乱数据流相比，记录 - > Action-> Store->食谱视图更清晰且易于管理。
前代码中有许多异步过程。这些异步过程之间可能存在串行，平行甚至更复杂的关系。在组件中管理不容易。它可以放置在Redux的中部。
Redux的中部是调度层。例如，redux-thunk是判断该动作是功能，否则它将继续派遣。
Redux-Thunk没有提供多种异步过程管理机制。复杂的异步过程的管理仍然必须使用Redux-Saga或Redux-Observable。
Redux-Saga将操作传输到存储，并监视操作以执行相应的异步过程。异步过程的描述使用生成器的形式，优势是可检验性。，然后执行Worker Saga.Worker Saga可以描述不同的副作用，以及诸如PUT，CALL，FORK之类的效果，并通过任务执行。
Redux-Observable还监视了相应的异步过程以执行相应的异步过程，但它基于RXJ。与传奇相比，异步过程的管理功能更强大。
所有这些都解决了复杂的异步过程的问题，并且可以根据场景的复杂性灵活选择。
作者：ZXG_上帝说必须有光