如何使用超时调度 Redux 操作?

我有一个操作可以更新我的应用程序的通知状态。通常,此通知将是错误或某种信息。然后,我需要在 5 秒钟后调度另一个操作,该操作会将通知状态恢复为初始状态,因此没有通知。其背后的主要原因是提供了 5 秒钟后通知自动消失的功能。

我没有使用setTimeout并返回另一个动作的运气,也找不到在线完成的方法。因此,欢迎提出任何建议。

答案

不要陷入认为图书馆应该规定如何做每件事陷阱 。如果要在 JavaScript 中进行超时操作,则需要使用setTimeout 。没有理由为什么 Redux 动作应该有所不同。

Redux 确实提供了一些替代方法来处理异步内容,但是只有在意识到重复过多代码时,才应使用这些方法。除非您有此问题,否则请使用语言提供的内容并寻求最简单的解决方案。

内联编写异步代码

到目前为止,这是最简单的方法。这里没有关于 Redux 的特定内容。

store.dispatch({ type: 'SHOW_NOTIFICATION', text: 'You logged in.' })
setTimeout(() => {
  store.dispatch({ type: 'HIDE_NOTIFICATION' })
}, 5000)

同样,从连接的组件内部:

this.props.dispatch({ type: 'SHOW_NOTIFICATION', text: 'You logged in.' })
setTimeout(() => {
  this.props.dispatch({ type: 'HIDE_NOTIFICATION' })
}, 5000)

唯一的区别是,在连接的组件中,您通常无权访问商店本身,而是获得dispatch()或特定动作创建者作为道具注入。但这对我们没有任何影响。

如果您不喜欢在从不同组件分派相同的动作时打错字,那么您可能希望提取动作创建者,而不是内联地分派动作对象:

// actions.js
export function showNotification(text) {
  return { type: 'SHOW_NOTIFICATION', text }
}
export function hideNotification() {
  return { type: 'HIDE_NOTIFICATION' }
}

// component.js
import { showNotification, hideNotification } from '../actions'

this.props.dispatch(showNotification('You just logged in.'))
setTimeout(() => {
  this.props.dispatch(hideNotification())
}, 5000)

或者,如果您之前已将它们与connect()绑定在一起:

this.props.showNotification('You just logged in.')
setTimeout(() => {
  this.props.hideNotification()
}, 5000)

到目前为止,我们还没有使用任何中间件或其他高级概念。

提取异步动作创建者

上面的方法在简单的情况下效果很好,但是您可能会发现它存在一些问题:

  • 它迫使您在要显示通知的任何地方重复此逻辑。
  • 通知没有 ID,因此如果您足够快地显示两个通知,您将处于竞争状态。当第一个超时结束时,它将调度HIDE_NOTIFICATION ,错误地将第二个通知隐藏在超时之后。

为了解决这些问题,您需要提取一个函数,该函数集中超时逻辑并调度这两个动作。它可能看起来像这样:

// actions.js
function showNotification(id, text) {
  return { type: 'SHOW_NOTIFICATION', id, text }
}
function hideNotification(id) {
  return { type: 'HIDE_NOTIFICATION', id }
}

let nextNotificationId = 0
export function showNotificationWithTimeout(dispatch, text) {
  // Assigning IDs to notifications lets reducer ignore HIDE_NOTIFICATION
  // for the notification that is not currently visible.
  // Alternatively, we could store the timeout ID and call
  // clearTimeout(), but we’d still want to do it in a single place.
  const id = nextNotificationId++
  dispatch(showNotification(id, text))

  setTimeout(() => {
    dispatch(hideNotification(id))
  }, 5000)
}

现在,组件可以使用showNotificationWithTimeout而无需复制此逻辑或使用不同的通知创建竞争条件:

// component.js
showNotificationWithTimeout(this.props.dispatch, 'You just logged in.')

// otherComponent.js
showNotificationWithTimeout(this.props.dispatch, 'You just logged out.')

为什么showNotificationWithTimeout()接受dispatch作为第一个参数?因为它需要将操作调度到商店。通常,组件可以访问dispatch但是由于我们希望外部函数控制调度,因此我们需要控制它。

如果您有从某个模块导出的单例商店,则可以将其导入并直接在其上dispatch

// store.js
export default createStore(reducer)

// actions.js
import store from './store'

// ...

let nextNotificationId = 0
export function showNotificationWithTimeout(text) {
  const id = nextNotificationId++
  store.dispatch(showNotification(id, text))

  setTimeout(() => {
    store.dispatch(hideNotification(id))
  }, 5000)
}

// component.js
showNotificationWithTimeout('You just logged in.')

// otherComponent.js
showNotificationWithTimeout('You just logged out.')

这看起来更简单,但是我们不建议您使用这种方法 。我们不喜欢它的主要原因是因为它迫使存储为单例 。这使得实现服务器渲染非常困难。在服务器上,您希望每个请求都有自己的存储,以便不同的用户获得不同的预加载数据。

单例存储也使测试更加困难。在测试操作创建者时,您不再可以模拟商店,因为他们引用了从特定模块导出的特定实际商店。您甚至无法从外部重置其状态。

因此,尽管从技术上讲您可以从模块中导出单例存储,但我们不建议这样做。除非您确定您的应用程序永远不会添加服务器渲染,否则请不要执行此操作。

回到以前的版本:

// actions.js

// ...

let nextNotificationId = 0
export function showNotificationWithTimeout(dispatch, text) {
  const id = nextNotificationId++
  dispatch(showNotification(id, text))

  setTimeout(() => {
    dispatch(hideNotification(id))
  }, 5000)
}

// component.js
showNotificationWithTimeout(this.props.dispatch, 'You just logged in.')

// otherComponent.js
showNotificationWithTimeout(this.props.dispatch, 'You just logged out.')

这解决了逻辑重复的问题,并使我们免于竞争条件。

Thunk 中间件

对于简单的应用程序,该方法就足够了。如果您对中间件感到满意,请不要担心。

但是,在大型应用程序中,可能会发现一些不便之处。

例如,不幸的是我们不得不传递dispatch 。这使得分隔容器组件和表示性组件变得更加棘手,因为以上述方式异步分派 Redux 动作的任何组件都必须接受dispatch作为道具,这样才能进一步传递它。您不能connect()动作创建者与connect()绑定在一起,因为showNotificationWithTimeout()并不是真正的动作创建者。它不返回 Redux 操作。

另外,记住哪些函数是同步动作创建者(例如showNotification()和哪些异步帮助showNotificationWithTimeout()例如showNotificationWithTimeout()可能很尴尬。您必须以不同的方式使用它们,并注意不要将它们彼此误认为是错误的。

这是寻找一种方法来 “合法化” 这种向助手功能提供dispatch的方式的动机,并帮助 Redux 将此类异步动作创建者 “视为” 正常动作创建者的特例,而不是完全不同的功能。

如果您仍然与我们在一起,并且还认为您的应用程序存在问题,欢迎您使用Redux Thunk中间件。

从本质上讲,Redux Thunk 教 Redux 识别实际上具有功能的特殊动作:

import { createStore, applyMiddleware } from 'redux'
import thunk from 'redux-thunk'

const store = createStore(
  reducer,
  applyMiddleware(thunk)
)

// It still recognizes plain object actions
store.dispatch({ type: 'INCREMENT' })

// But with thunk middleware, it also recognizes functions
store.dispatch(function (dispatch) {
  // ... which themselves may dispatch many times
  dispatch({ type: 'INCREMENT' })
  dispatch({ type: 'INCREMENT' })
  dispatch({ type: 'INCREMENT' })

  setTimeout(() => {
    // ... even asynchronously!
    dispatch({ type: 'DECREMENT' })
  }, 1000)
})

启用此中间件后, 如果您调度一个函数 ,则 Redux Thunk 中间件将为其dispatch参数。它还会 “吞噬” 这样的动作,因此不必担心您的 reducer 会收到奇怪的函数参数。减速器将仅接收普通对象操作 - 直接发出或由我们刚刚描述的函数发出。

这看起来不是很有用,是吗?不在这种特殊情况下。但是,它使我们可以将showNotificationWithTimeout()声明为常规 Redux 操作创建者:

// actions.js
function showNotification(id, text) {
  return { type: 'SHOW_NOTIFICATION', id, text }
}
function hideNotification(id) {
  return { type: 'HIDE_NOTIFICATION', id }
}

let nextNotificationId = 0
export function showNotificationWithTimeout(text) {
  return function (dispatch) {
    const id = nextNotificationId++
    dispatch(showNotification(id, text))

    setTimeout(() => {
      dispatch(hideNotification(id))
    }, 5000)
  }
}

请注意,该函数与上一节中编写的函数几乎相同。但是,它不接受dispatch作为第一个参数。而是返回一个函数,该函数接受dispatch作为第一个参数。

我们将如何在组件中使用它?绝对可以这样写:

// component.js
showNotificationWithTimeout('You just logged in.')(this.props.dispatch)

我们正在调用异步动作创建者来获取要dispatch的内部函数,然后传递dispatch

但是,这比原始版本更尴尬!我们为什么还要那样走?

因为我之前告诉过你如果启用了 Redux Thunk 中间件,则任何时候您尝试分派一个函数而不是一个操作对象时,中间件都将使用dispatch方法本身作为第一个参数来调用该函数

因此,我们可以改为:

// component.js
this.props.dispatch(showNotificationWithTimeout('You just logged in.'))

最后,分派异步操作(实际上是一系列操作)看起来与向组件同步分派单个操作没有什么不同。这样做很好,因为组件不必关心是同步还是异步发生。我们只是将其抽象出来。

请注意,由于我们 “教” Redux 来识别此类 “特殊” 动作创建者(我们称其为 “ 笨拙的动作创建者”),因此我们现在可以在将使用常规动作创建者的任何地方使用它们。例如,我们可以将它们与connect()

// actions.js

function showNotification(id, text) {
  return { type: 'SHOW_NOTIFICATION', id, text }
}
function hideNotification(id) {
  return { type: 'HIDE_NOTIFICATION', id }
}

let nextNotificationId = 0
export function showNotificationWithTimeout(text) {
  return function (dispatch) {
    const id = nextNotificationId++
    dispatch(showNotification(id, text))

    setTimeout(() => {
      dispatch(hideNotification(id))
    }, 5000)
  }
}

// component.js

import { connect } from 'react-redux'

// ...

this.props.showNotificationWithTimeout('You just logged in.')

// ...

export default connect(
  mapStateToProps,
  { showNotificationWithTimeout }
)(MyComponent)

阅读《 Thunks》中的状态

通常,减速器包含用于确定下一个状态的业务逻辑。但是,减速器仅在分派动作后才启动。如果您在重动作创建器中有副作用(例如,调用 API),并且想要在某种情况下避免这种情况该怎么办?

无需使用笨拙的中间件,您只需在组件内部进行以下检查:

// component.js
if (this.props.areNotificationsEnabled) {
  showNotificationWithTimeout(this.props.dispatch, 'You just logged in.')
}

但是,提取动作创建者的目的是将重复性逻辑集中在许多组件上。幸运的是,Redux Thunk 为您提供了一种读取 Redux 存储库当前状态的方法。除了dispatch ,它还将getState作为第二个参数传递给您从 thunk 动作创建者返回的函数。这使 thunk 可以读取商店的当前状态。

let nextNotificationId = 0
export function showNotificationWithTimeout(text) {
  return function (dispatch, getState) {
    // Unlike in a regular action creator, we can exit early in a thunk
    // Redux doesn’t care about its return value (or lack of it)
    if (!getState().areNotificationsEnabled) {
      return
    }

    const id = nextNotificationId++
    dispatch(showNotification(id, text))

    setTimeout(() => {
      dispatch(hideNotification(id))
    }, 5000)
  }
}

不要滥用这种模式。当有可用的缓存数据时,这有助于避免 API 调用,但它并不是建立业务逻辑的良好基础。如果仅使用getState()有条件地分派不同的操作,请考虑将业务逻辑放入简化器中。

下一步

现在,您已经了解了 thunk 的工作原理,请查看使用它们的 Redux 异步示例

您可能会发现许多示例,其中 thunk 返回 Promises。这不是必需的,但可能非常方便。 Redux 不在乎您从 thunk 返回什么,但是它为您提供了dispatch()返回值。这就是为什么您可以从 thunk 中返回 Promise 并通过调用dispatch(someThunkReturningPromise()).then(...)等待其完成的dispatch(someThunkReturningPromise()).then(...)

您也可以将复杂的重击动作创建者拆分为几个较小的重击动作创建者。 thunk 提供的dispatch方法本身可以接受 thunk,因此您可以递归应用模式。同样,这对 Promises 效果最好,因为您可以在此之上实现异步控制流。

对于某些应用程序,您可能会发现自己的异步控制流需求过于复杂而无法用笨拙的东西来表达。例如,以这种方式编写时,重试失败的请求,使用令牌的重新授权流程或分步入职可能太冗长且容易出错。在这种情况下,您可能希望查看更高级的异步控制流解决方案,例如Redux SagaRedux Loop 。评估它们,比较与您的需求相关的示例,然后选择最喜欢的示例。

最后,如果您没有真正的需求,请不要使用任何东西(包括音乐)。请记住,根据要求,您的解决方案可能看起来像

store.dispatch({ type: 'SHOW_NOTIFICATION', text: 'You logged in.' })
setTimeout(() => {
  store.dispatch({ type: 'HIDE_NOTIFICATION' })
}, 5000)

除非您知道为什么要这么做,否则不要流汗。

使用 Redux-saga

正如 Dan Abramov 所说,如果您想对异步代码进行更高级的控制,可以看看redux-saga

这个答案是一个简单的示例,如果您想更好地解释为什么 redux-saga 对您的应用程序有用,请查看其他答案

通常的想法是 Redux-saga 提供了一个 ES6 生成器解释器,使您可以轻松编写看起来像同步代码的异步代码(这就是为什么您经常在 Redux-saga 中发现无限 while 循环的原因)。 Redux-saga 不知何故直接在 Javascript 中构建了自己的语言。刚开始学习 Redux-saga 时会感到有些困难,因为您需要对生成器有基本的了解,而且还需要了解 Redux-saga 所提供的语言。

我将在这里尝试描述我基于 redux-saga 构建的通知系统。此示例当前在生产中运行。

高级通知系统规范

  • 您可以请求显示通知
  • 您可以请求隐藏通知
  • 通知显示的时间不得超过 4 秒
  • 可以同时显示多个通知
  • 一次最多只能显示 3 条通知
  • 如果在已经显示 3 条通知的情况下请求通知,则将其排队 / 推迟。

结果

我的生产应用Stample.co 的屏幕截图

敬酒

在这里,我将通知命名为toast但这是一个命名细节。

function* toastSaga() {

    // Some config constants
    const MaxToasts = 3;
    const ToastDisplayTime = 4000;


    // Local generator state: you can put this state in Redux store
    // if it's really important to you, in my case it's not really
    let pendingToasts = []; // A queue of toasts waiting to be displayed
    let activeToasts = []; // Toasts currently displayed


    // Trigger the display of a toast for 4 seconds
    function* displayToast(toast) {
        if ( activeToasts.length >= MaxToasts ) {
            throw new Error("can't display more than " + MaxToasts + " at the same time");
        }
        activeToasts = [...activeToasts,toast]; // Add to active toasts
        yield put(events.toastDisplayed(toast)); // Display the toast (put means dispatch)
        yield call(delay,ToastDisplayTime); // Wait 4 seconds
        yield put(events.toastHidden(toast)); // Hide the toast
        activeToasts = _.without(activeToasts,toast); // Remove from active toasts
    }

    // Everytime we receive a toast display request, we put that request in the queue
    function* toastRequestsWatcher() {
        while ( true ) {
            // Take means the saga will block until TOAST_DISPLAY_REQUESTED action is dispatched
            const event = yield take(Names.TOAST_DISPLAY_REQUESTED);
            const newToast = event.data.toastData;
            pendingToasts = [...pendingToasts,newToast];
        }
    }


    // We try to read the queued toasts periodically and display a toast if it's a good time to do so...
    function* toastScheduler() {
        while ( true ) {
            const canDisplayToast = activeToasts.length < MaxToasts && pendingToasts.length > 0;
            if ( canDisplayToast ) {
                // We display the first pending toast of the queue
                const [firstToast,...remainingToasts] = pendingToasts;
                pendingToasts = remainingToasts;
                // Fork means we are creating a subprocess that will handle the display of a single toast
                yield fork(displayToast,firstToast);
                // Add little delay so that 2 concurrent toast requests aren't display at the same time
                yield call(delay,300);
            }
            else {
                yield call(delay,50);
            }
        }
    }

    // This toast saga is a composition of 2 smaller "sub-sagas" (we could also have used fork/spawn effects here, the difference is quite subtile: it depends if you want toastSaga to block)
    yield [
        call(toastRequestsWatcher),
        call(toastScheduler)
    ]
}

减速器:

const reducer = (state = [],event) => {
    switch (event.name) {
        case Names.TOAST_DISPLAYED:
            return [...state,event.data.toastData];
        case Names.TOAST_HIDDEN:
            return _.without(state,event.data.toastData);
        default:
            return state;
    }
};

用法

您可以简单地调度TOAST_DISPLAY_REQUESTED事件。如果您分派 4 个请求,则仅会显示 3 条通知,而第 1 条通知消失后,第 4 条通知将在稍后出现。

请注意,我不特别建议从 JSX 派遣TOAST_DISPLAY_REQUESTED 。您宁愿添加另一个传奇来侦听您已经存在的应用程序事件,然后调度TOAST_DISPLAY_REQUESTED :触发通知的组件不必与通知系统紧密耦合。

结论

我的代码不是完美的,但是在生产中运行了几个月的 0 个错误。 Redux-saga 和生成器最初有点困难,但是一旦您了解了它们,这种系统就很容易构建。

实施更复杂的规则非常容易,例如:

  • 当过多的通知被 “排队” 时,为每个通知提供更少的显示时间,以便队列大小可以更快地减小。
  • 检测窗口大小的变化,并相应地更改显示的最大通知数(例如,桌面 = 3,电话肖像 = 2,电话横向 = 1)

坦白地说,祝您好运,并与流氓正确地实现这种东西。

请注意,您可以使用redux-observable进行完全相同的操作,这与 redux-saga 非常相似。几乎相同,并且是生成器和 RxJS 之间的品味问题。

具有示例项目的存储库

当前有四个样本项目:

  1. 内联编写异步代码
  2. 提取异步动作创建者
  3. 使用 Redux Thunk
  4. 使用 Redux Saga

公认的答案很棒。

但是缺少一些东西:

  1. 没有可运行的示例项目,只有一些代码片段。
  2. 没有其他替代方法的示例代码,例如:
    1. Redux Saga

因此,我创建了Hello Async存储库以添加缺少的内容:

  1. 可运行的项目。您可以下载并运行它们而无需修改。
  2. 提供示例代码以获取更多替代方案:

Redux Saga

接受的答案已经提供了异步代码内联,异步动作生成器和 Redux Thunk 的示例代码片段。为了完整起见,我提供了 Redux Saga 的代码段:

// actions.js

export const showNotification = (id, text) => {
  return { type: 'SHOW_NOTIFICATION', id, text }
}

export const hideNotification = (id) => {
  return { type: 'HIDE_NOTIFICATION', id }
}

export const showNotificationWithTimeout = (text) => {
  return { type: 'SHOW_NOTIFICATION_WITH_TIMEOUT', text }
}

动作简单而纯粹。

// component.js

import { connect } from 'react-redux'

// ...

this.props.showNotificationWithTimeout('You just logged in.')

// ...

export default connect(
  mapStateToProps,
  { showNotificationWithTimeout }
)(MyComponent)

组件没有什么特别的。

// sagas.js

import { takeEvery, delay } from 'redux-saga'
import { put } from 'redux-saga/effects'
import { showNotification, hideNotification } from './actions'

// Worker saga
let nextNotificationId = 0
function* showNotificationWithTimeout (action) {
  const id = nextNotificationId++
  yield put(showNotification(id, action.text))
  yield delay(5000)
  yield put(hideNotification(id))
}

// Watcher saga, will invoke worker saga above upon action 'SHOW_NOTIFICATION_WITH_TIMEOUT'
function* notificationSaga () {
  yield takeEvery('SHOW_NOTIFICATION_WITH_TIMEOUT', showNotificationWithTimeout)
}

export default notificationSaga

Sagas 基于ES6 生成器

// index.js

import createSagaMiddleware from 'redux-saga'
import saga from './sagas'

const sagaMiddleware = createSagaMiddleware()

const store = createStore(
  reducer,
  applyMiddleware(sagaMiddleware)
)

sagaMiddleware.run(saga)

与 Redux Thunk 相比

优点

  • 您不会陷入回调地狱。
  • 您可以轻松测试异步流。
  • 您的行为保持纯正。

缺点

  • 它取决于相对较新的 ES6 Generators。

如果上面的代码段不能回答您所有的问题,请参考可运行的项目

您可以使用redux-thunk做到这一点。 在 redux 文档中有一个指南,用于诸如 setTimeout 之类的异步操作。

我建议您也看看SAM 模式

SAM 模式提倡包括 “下一个动作谓词”,其中,一旦模型更新(SAM 模型〜减速器状态 + 存储),就会触发诸如 “通知在 5 秒后自动消失” 之类的(自动)动作。

该模式提倡一次对动作和模型变异进行排序,因为模型的 “控制状态”“控制” 动作由下一动作谓词启用和 / 或自动执行。您根本无法预测(一般而言)在处理操作之前系统将处于什么状态,因此无法预测是否将允许 / 可能执行您的下一个预期操作。

例如,代码

export function showNotificationWithTimeout(dispatch, text) {
  const id = nextNotificationId++
  dispatch(showNotification(id, text))

  setTimeout(() => {
    dispatch(hideNotification(id))
  }, 5000)
}

不会允许 SAM,因为可以调度 hideNotification 动作的事实取决于模型是否成功接受值 “showNotication:true”。模型中可能有其他部分阻止它接受它,因此,没有理由触发 hideNotification 操作。

我强烈建议在商店更新并且可以知道模型的新控制状态之后,实施适当的 next-action 谓词。这是实现您正在寻找的行为的最安全的方法。

您可以根据需要加入 Gitter。这里还有SAM 入门指南

在尝试了各种流行的方法(动作创建者,重击,萨加斯,史诗,特效,自定义中间件)之后,我仍然觉得也许还有改进的余地,所以我在这篇博客文章 “ 在哪里放置业务逻辑” 中记录了自己的旅程。一个 React / Redux 应用程序?

就像这里的讨论一样,我试图对比和比较各种方法。最终,它使我引入了一个新的库redux-logic ,该库从史诗,sagas 和自定义中间件中汲取了灵感。

它使您可以拦截用于验证,验证,授权的操作,并提供执行异步 IO 的方法。

可以简单地声明一些常用功能,例如反跳,限制,取消,并且仅使用最新请求(takeLatest)的响应。 redux-logic 会包装您的代码,为您提供此功能。

这使您可以自由地执行自己喜欢的核心业务逻辑。除非您愿意,否则不必使用观测器或生成器。使用函数和回调,promise,异步函数(异步 / 等待)等。

执行简单的 5s 通知的代码如下所示:

const notificationHide = createLogic({
  // the action type that will trigger this logic
  type: 'NOTIFICATION_DISPLAY',
  
  // your business logic can be applied in several
  // execution hooks: validate, transform, process
  // We are defining our code in the process hook below
  // so it runs after the action hit reducers, hide 5s later
  process({ getState, action }, dispatch) {
    setTimeout(() => {
      dispatch({ type: 'NOTIFICATION_CLEAR' });
    }, 5000);
  }
});

我在仓库中有一个更高级的通知示例,该示例的工作方式类似于塞巴斯蒂安 · 洛伯(Sebastian Lorber)所描述的,您可以在其中将显示限制为 N 个项目,并轮流浏览所有排队的项目。 redux-logic 通知示例

我有各种redux-logic jsfiddle 实时示例以及完整示例 。我正在继续研究文档和示例。

我希望听到您的反馈。

我知道这个问题有点老了,但我将介绍另一个使用redux-observable aka 的解决方案。史诗。

引用官方文档:

什么是可观察到的 redux?

用于 Redux 的基于 RxJS 5 的中间件。撰写和取消异步操作以创建副作用等。

史诗是 redux-observable 的核心原语。

它是一个函数,它接受一系列操作并返回一系列操作。行动起来,行动出来。

换句话说,您可以创建一个函数,该函数通过 Stream 接收动作,然后返回新的动作流(使用超时,延迟,间隔和请求等常见副作用)。

让我发布代码,然后再解释一下

store.js

import {createStore, applyMiddleware} from 'redux'
import {createEpicMiddleware} from 'redux-observable'
import {Observable} from 'rxjs'
const NEW_NOTIFICATION = 'NEW_NOTIFICATION'
const QUIT_NOTIFICATION = 'QUIT_NOTIFICATION'
const NOTIFICATION_TIMEOUT = 2000

const initialState = ''
const rootReducer = (state = initialState, action) => {
  const {type, message} = action
  console.log(type)
  switch(type) {
    case NEW_NOTIFICATION:
      return message
    break
    case QUIT_NOTIFICATION:
      return initialState
    break
  }

  return state
}

const rootEpic = (action$) => {
  const incoming = action$.ofType(NEW_NOTIFICATION)
  const outgoing = incoming.switchMap((action) => {
    return Observable.of(quitNotification())
      .delay(NOTIFICATION_TIMEOUT)
      //.takeUntil(action$.ofType(NEW_NOTIFICATION))
  });

  return outgoing;
}

export function newNotification(message) {
  return ({type: NEW_NOTIFICATION, message})
}
export function quitNotification(message) {
  return ({type: QUIT_NOTIFICATION, message});
}

export const configureStore = () => createStore(
  rootReducer,
  applyMiddleware(createEpicMiddleware(rootEpic))
)

index.js

import React from 'react';
import ReactDOM from 'react-dom';
import App from './App';
import {configureStore} from './store.js'
import {Provider} from 'react-redux'

const store = configureStore()

ReactDOM.render(
  <Provider store={store}>
    <App />
  </Provider>,
  document.getElementById('root')
);

App.js

import React, { Component } from 'react';
import {connect} from 'react-redux'
import {newNotification} from './store.js'

class App extends Component {

  render() {
    return (
      <div className="App">
        {this.props.notificationExistance ? (<p>{this.props.notificationMessage}</p>) : ''}
        <button onClick={this.props.onNotificationRequest}>Click!</button>
      </div>
    );
  }
}

const mapStateToProps = (state) => {
  return {
    notificationExistance : state.length > 0,
    notificationMessage : state
  }
}

const mapDispatchToProps = (dispatch) => {
  return {
    onNotificationRequest: () => dispatch(newNotification(new Date().toDateString()))
  }
}

export default connect(mapStateToProps, mapDispatchToProps)(App)

如您所见,解决此问题的关键代码非常容易,唯一看起来与其他答案不同的是函数 rootEpic。

要点 1. 与 sagas 一样,您必须组合史诗才能获得一个顶级功能,该功能可以接收动作流并返回动作流,因此可以将其与中间件工厂createEpicMiddleware 一起使用 。在我们的例子中,我们只需要一个,所以我们只有rootEpic,因此我们不需要合并任何东西,但是很容易知道事实。

要点 2。我们关心副作用逻辑的rootEpic只需要大约 5 行代码,真是太棒了!包括几乎是声明性的事实!

点 3. 逐行 rootEpic 解释(在注释中)

const rootEpic = (action$) => {
  // sets the incoming constant as a stream 
  // of actions with  type NEW_NOTIFICATION
  const incoming = action$.ofType(NEW_NOTIFICATION)
  // Merges the "incoming" stream with the stream resulting for each call
  // This functionality is similar to flatMap (or Promise.all in some way)
  // It creates a new stream with the values of incoming and 
  // the resulting values of the stream generated by the function passed
  // but it stops the merge when incoming gets a new value SO!,
  // in result: no quitNotification action is set in the resulting stream
  // in case there is a new alert
  const outgoing = incoming.switchMap((action) => {
    // creates of observable with the value passed 
    // (a stream with only one node)
    return Observable.of(quitNotification())
      // it waits before sending the nodes 
      // from the Observable.of(...) statement
      .delay(NOTIFICATION_TIMEOUT)
  });
  // we return the resulting stream
  return outgoing;
}

希望对您有所帮助!

为什么要这么难?这只是 UI 逻辑。使用专用操作来设置通知数据:

dispatch({ notificationData: { message: 'message', expire: +new Date() + 5*1000 } })

并显示它的专用组件:

const Notifications = ({ notificationData }) => {
    if(notificationData.expire > this.state.currentTime) {
      return <div>{notificationData.message}</div>
    } else return null;
}

在这种情况下,问题应该是 “如何清理旧状态?”,“如何通知组件时间已更改”。

您可以实现一些 TIMEOUT 操作,该操作是在组件的 setTimeout 上分派的。

也许每当显示新通知时清理它就好。

无论如何,应该在某个地方设置一些setTimeout ,对吗?为什么不在组件中这样做

setTimeout(() => this.setState({ currentTime: +new Date()}), 
           this.props.notificationData.expire-(+new Date()) )

其动机是 “通知淡出” 功能确实是 UI 的关注点。因此,它简化了对业务逻辑的测试。

测试它的实现方式似乎没有任何意义。验证通知何时应该超时才有意义。因此,更少的代码存根,更快的测试,更干净的代码。

如果要对选择性操作进行超时处理,可以尝试使用中间件方法。在选择性地处理基于承诺的操作时,我也遇到了类似的问题,该解决方案更加灵活。

假设您的动作创建者如下所示:

//action creator
buildAction = (actionData) => ({
    ...actionData,
    timeout: 500
})

超时可以在上述操作中保存多个值

  • 以毫秒为单位的数字 - 特定的超时时间
  • true - 恒定的持续时间。 (在中间件中处理)
  • 未定义 - 立即发货

您的中间件实现如下所示:

//timeoutMiddleware.js
const timeoutMiddleware = store => next => action => {

  //If your action doesn't have any timeout attribute, fallback to the default handler
  if(!action.timeout) {
    return next (action)
  }

  const defaultTimeoutDuration = 1000;
  const timeoutDuration = Number.isInteger(action.timeout) ? action.timeout || defaultTimeoutDuration;

//timeout here is called based on the duration defined in the action.
  setTimeout(() => {
    next (action)
  }, timeoutDuration)
}

现在,您可以使用 redux 通过此中间件层路由所有操作。

createStore(reducer, applyMiddleware(timeoutMiddleware))

您可以在这里找到一些类似的例子

正确的方法是使用Redux Thunk ,根据 Redux Thunk 文档, Redux ThunkRedux的流行中间件:

“Redux Thunk 中间件允许您编写返回函数而不是动作的动作创建者。thunk 可用于延迟动作的分配,或者仅在满足特定条件时才分配。内部函数接收存储方法 dispatch 和 getState 作为参数”。

因此,基本上它返回一个函数,您可以延迟调度或将其置于条件状态。

因此,类似这样的事情将为您完成工作:

import ReduxThunk from 'redux-thunk';

const INCREMENT_COUNTER = 'INCREMENT_COUNTER';

function increment() {
  return {
    type: INCREMENT_COUNTER
  };
}

function incrementAsync() {
  return dispatch => {
    setTimeout(() => {
      // Yay! Can invoke sync or async actions with `dispatch`
      dispatch(increment());
    }, 5000);
  };
}