Redux本身是一个非常冗长的库，对于这样的东西，你必须使用像Redux-thunk这样的东西，它会提供一个分派函数，所以你将能够在几秒钟后分派关闭通知。

我已经创建了一个库来解决诸如冗长性和可组合性等问题，您的示例将如下所示:

import { createTile, createSyncTile } from 'redux-tiles';
import { sleep } from 'delounce';

const notifications = createSyncTile({
  type: ['ui', 'notifications'],
  fn: ({ params }) => params.data,
  // to have only one tile for all notifications
  nesting: ({ type }) => [type],
});

const notificationsManager = createTile({
  type: ['ui', 'notificationManager'],
  fn: ({ params, dispatch, actions }) => {
    dispatch(actions.ui.notifications({ type: params.type, data: params.data }));
    await sleep(params.timeout || 5000);
    dispatch(actions.ui.notifications({ type: params.type, data: null }));
    return { closed: true };
  },
  nesting: ({ type }) => [type],
});

因此，我们在异步动作中组合同步动作来显示通知，这可以请求一些后台信息，或者稍后检查通知是否被手动关闭。

在尝试了各种流行的方法(动作创造者，坦克，传奇，史诗，效果，自定义中间件)后，我仍然觉得可能还有改进的空间，所以我在这篇博客文章中记录了我的旅程，在React/Redux应用程序中我应该把我的业务逻辑放在哪里?

就像这里的讨论一样，我尝试对比和比较各种方法。最终，我引入了一个新的redux-logic库，它的灵感来自史诗、传奇故事和自定义中间件。

它允许您拦截验证、验证、授权的操作，并提供了一种执行异步IO的方法。

一些常见的功能可以简单地声明，如debashing、节流、取消，并且只使用来自最新请求的响应(takeLatest)。Redux-logic包装为您提供此功能的代码。

这使您可以随心所欲地实现核心业务逻辑。除非你愿意，否则你不必使用可观察对象或生成器。使用函数和回调，承诺，异步函数(async/await)等。

做一个简单的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); } });

在我的repo中，我有一个更高级的通知示例，其工作原理类似于Sebastian Lorber所描述的，您可以将显示限制为N个项目，并通过任何排队的项目进行旋转。Redux-logic通知示例

我有各种redux-logic jsfiddle现场的例子，以及完整的例子。我还在继续写文档和例子。

我很想听听你的反馈。

我建议大家也看看SAM模式。

SAM模式提倡包含“下一个动作-谓词”，其中一旦模型更新(SAM模型~ reducer状态+ store)，就会触发(自动)动作，例如“通知在5秒后自动消失”。

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

比如代码，

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

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

在SAM中是不允许的，因为hideNotification动作可以被分派的事实依赖于模型成功接受值" shownotice: true"。模型的其他部分可能阻止它接受，因此，没有理由触发hideNotification操作。

我强烈建议在存储更新和模型的新控件状态可以知道之后实现适当的下一个操作谓词。这是实现您正在寻找的行为的最安全的方法。

如果你愿意，可以在Gitter上加入我们。这里还有一个SAM入门指南。

如果希望对选择性操作进行超时处理，可以尝试中间件方法。 我遇到过一个类似的问题，有选择地处理基于承诺的行为，这个解决方案更灵活。

假设你的动作创造者是这样的:

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

Timeout可以在上述操作中包含多个值

以毫秒为单位的数字-用于指定的超时时间 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操作只能返回一个普通对象，而不是函数、回调或异步进程。为了通过web API(如timeout()方法)分派它们，你必须使用redux-thunk中间件。创建它是为了处理这样的流程。

首先通过文档配置redux-thunk 第二，这样改变你的动作创建器:

const yourAction = millisecond => dispatch => {
   setTimeout(() => {
      dispatch({
         type: 'YOUR_ACTIION_TYPE',
         payload: yourWhatEverPayload
      })
   }, millisecond)
}

为什么这么难呢?这只是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关注点。因此，它简化了业务逻辑的测试。

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