使用 Redux Observable 等待操作序列

本文介绍了使用 Redux Observable 等待操作序列的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我有一个用例，在使用 Redux Observables 调度另一个操作之前，我需要等待一系列操作.我见过一些类似的问题，但我无法理解如何将这些方法用于给定的用例.

I have a use case where I need to wait for a sequence of actions before I dispatch another using Redux Observables. I've seen some similar questions but I cannot fathom how I can use these approaches for my given use case.

本质上我想做这样的事情:

In essence I want to do something like so:

action$ .ofType(PAGINATION_CLICKED) // This action occurred. .ofType(FETCH_SUCCESS) // Then this action occurred after. .map(() => analyticsAction()); // Dispatch analytics.

例如，如果另一个 FETCH_ERROR 类型的操作触发，我还想取消并重新开始该序列.

I would also like to cancel and start that sequence over again if another action of type FETCH_ERROR fires for example.

推荐答案

很好的问题.重要的一点是 action$ 是所有操作被分派时的热/多播流(它是一个主题).由于它很热，我们可以多次组合它，它们都会监听相同的动作流.

Great question. The important point is that action$ is a hot/multicast stream of all actions as they are dispatched (it's a Subject). Since it's hot we can combine it multiple times and they'll all be listening to the same stream of actions.

// uses switchMap so if another PAGINATION_CLICKED comes in // before FETCH_SUCCESS we start over action$ .ofType(PAGINATION_CLICKED) .switchMap(() => action$.ofType(FETCH_SUCCESS) .take(1) // <-------------------- very important! .map(() => analyticsAction()) .takeUntil(action$.ofType(FETCH_ERROR)) );

因此，每次我们收到 PAGINATION_CLICKED 时，我们都会开始侦听内部 Observable 链，该链侦听单个 FETCH_SUCCESS.拥有 .take(1) 很重要，否则我们将继续侦听多个 FETCH_SUCCESS，这可能会导致奇怪的错误，即使不是，通常也是最好的练习只拿你需要的东西.

So every time we receive PAGINATION_CLICKED we'll start listening to that inner Observable chain that listens for a single FETCH_SUCCESS. It's important to have that .take(1) because otherwise we'd continue to listen for more than one FETCH_SUCCESS which might cause strange bugs and even if not is just generally best practice to only take what you need.

如果我们首先收到 FETCH_ERROR，我们使用 takeUntil 取消等待 FETCH_SUCCESS.

We use takeUntil to cancel waiting for FETCH_SUCCESS if we receive FETCH_ERROR first.

作为奖励，如果您决定还想根据错误进行一些分析，不仅要重新开始，您还可以使用 race 在两个流之间进行比赛.第一个发出，获胜；另一个已取消订阅.

As a bonus, if you decide you want also to do some analytics stuff based on the error too, not only start over, you can use race to indeed race between the two streams. First one to emit, wins; the other is unsubscribed.

action$ .ofType(PAGINATION_CLICKED) .switchMap(() => Observable.race( action$.ofType(FETCH_SUCCESS) .take(1) .map(() => analyticsAction()), action$.ofType(FETCH_ERROR) .take(1) .map(() => someOtherAnalyticsAction()) ) );

这是同样的事情，但使用 race 作为实例运算符而不是静态运算符.这是您可以选择的风格偏好.他们都做同样的事情.使用您更清楚的那个.

Here's the same thing, but using race as an instance operator instead of the static one. This is a stylistic preference you can choose. They both do the same thing. Use whichever one is more clear to you.

action$ .ofType(PAGINATION_CLICKED) .switchMap(() => action$.ofType(FETCH_SUCCESS) .map(() => analyticsAction()) .race( action$.ofType(FETCH_ERROR) .map(() => someOtherAnalyticsAction()) ) .take(1) );