为什么我们需要Redux中的异步流中间件？

时间：2016-01-02 21:09:48

标签： javascript asynchronous reactjs redux redux-thunk

根据文件，"Without middleware, Redux store only supports synchronous data flow"。我不明白为什么会这样。为什么容器组件不能调用异步API，然后dispatch这些操作？

例如，想象一个简单的UI：字段和按钮。当用户按下按钮时，该字段将填充来自远程服务器的数据。

A field and a button 

import * as React from 'react';
import * as Redux from 'redux';
import { Provider, connect } from 'react-redux';

const ActionTypes = {
    STARTED_UPDATING: 'STARTED_UPDATING',
    UPDATED: 'UPDATED'
};

class AsyncApi {
    static getFieldValue() {
        const promise = new Promise((resolve) => {
            setTimeout(() => {
                resolve(Math.floor(Math.random() * 100));
            }, 1000);
        });
        return promise;
    }
}

class App extends React.Component {
    render() {
        return (
            <div>
                <input value={this.props.field}/>
                <button disabled={this.props.isWaiting} onClick={this.props.update}>Fetch</button>
                {this.props.isWaiting && <div>Waiting...</div>}
            </div>
        );
    }
}
App.propTypes = {
    dispatch: React.PropTypes.func,
    field: React.PropTypes.any,
    isWaiting: React.PropTypes.bool
};

const reducer = (state = { field: 'No data', isWaiting: false }, action) => {
    switch (action.type) {
        case ActionTypes.STARTED_UPDATING:
            return { ...state, isWaiting: true };
        case ActionTypes.UPDATED:
            return { ...state, isWaiting: false, field: action.payload };
        default:
            return state;
    }
};
const store = Redux.createStore(reducer);
const ConnectedApp = connect(
    (state) => {
        return { ...state };
    },
    (dispatch) => {
        return {
            update: () => {
                dispatch({
                    type: ActionTypes.STARTED_UPDATING
                });
                AsyncApi.getFieldValue()
                    .then(result => dispatch({
                        type: ActionTypes.UPDATED,
                        payload: result
                    }));
            }
        };
    })(App);
export default class extends React.Component {
    render() {
        return <Provider store={store}><ConnectedApp/></Provider>;
    }
}

渲染导出的组件时，我可以单击该按钮并正确更新输入。

请注意update来电中的connect功能。它调度一个动作，告诉应用程序它正在更新，然后执行异步调用。调用完成后，将提供的值作为另一个操作的有效负载进行调度。

这种方法有什么问题？为什么我要使用Redux Thunk或Redux Promise，正如文档建议的那样？

编辑：我搜索了Redux仓库的线索，发现Action Creators过去需要纯函数。例如，here's a user trying to provide a better explanation for async data flow:

  

动作创建者本身仍然是一个纯函数，但它返回的thunk函数不需要，它可以执行我们的异步调用

Action creators are no longer required to be pure.所以，过去肯定需要thunk / promise中间件，但似乎不再是这种情况了？

11 个答案:

答案 0 :(得分：535)

  

这种方法有什么问题？为什么我要使用Redux Thunk或Redux Promise，正如文档建议的那样？

这种方法没有错。这在大型应用程序中不方便，因为您将有不同的组件执行相同的操作，您可能想要去除某些操作，或保持一些本地状态，如自动递增ID靠近动作创建者等等。所以它更容易从维护的观点是将动作创建者提取到单独的函数中。

您可以阅读my answer to “How to dispatch a Redux action with a timeout”了解更详细的演练。

像Redux Thunk或Redux Promise这样的中间件只是为你发送thunk或promises提供了“语法糖”，但你不必使用它。

因此，没有任何中间件，您的动作创建者可能看起来像

// action creator
function loadData(dispatch, userId) { // needs to dispatch, so it is first argument
  return fetch(`http://data.com/${userId}`)
    .then(res => res.json())
    .then(
      data => dispatch({ type: 'LOAD_DATA_SUCCESS', data }),
      err => dispatch({ type: 'LOAD_DATA_FAILURE', err })
    );
}

// component
componentWillMount() {
  loadData(this.props.dispatch, this.props.userId); // don't forget to pass dispatch
}

但是使用Thunk Middleware你可以这样写：

// action creator
function loadData(userId) {
  return dispatch => fetch(`http://data.com/${userId}`) // Redux Thunk handles these
    .then(res => res.json())
    .then(
      data => dispatch({ type: 'LOAD_DATA_SUCCESS', data }),
      err => dispatch({ type: 'LOAD_DATA_FAILURE', err })
    );
}

// component
componentWillMount() {
  this.props.dispatch(loadData(this.props.userId)); // dispatch like you usually do
}

所以没有太大的区别。我喜欢后一种方法的一件事是组件不关心动作创建者是异步的。它只是正常调用dispatch，它也可以使用mapDispatchToProps用短语法绑定这样的动作创建器等。组件不知道如何实现动作创建器，并且可以在不同的异步之间切换方法（Redux Thunk，Redux Promise，Redux Saga）无需更改组件。另一方面，使用前一种显式方法，您的组件知道完全特定调用是异步的，并且需要dispatch通过某种约定传递（例如，作为同步参数）。

还要考虑一下这段代码将如何变化。假设我们想要第二个数据加载函数，并将它们组合在一个动作创建器中。

使用第一种方法，我们需要注意我们正在调用什么样的动作创建者：

// action creators
function loadSomeData(dispatch, userId) {
  return fetch(`http://data.com/${userId}`)
    .then(res => res.json())
    .then(
      data => dispatch({ type: 'LOAD_SOME_DATA_SUCCESS', data }),
      err => dispatch({ type: 'LOAD_SOME_DATA_FAILURE', err })
    );
}
function loadOtherData(dispatch, userId) {
  return fetch(`http://data.com/${userId}`)
    .then(res => res.json())
    .then(
      data => dispatch({ type: 'LOAD_OTHER_DATA_SUCCESS', data }),
      err => dispatch({ type: 'LOAD_OTHER_DATA_FAILURE', err })
    );
}
function loadAllData(dispatch, userId) {
  return Promise.all(
    loadSomeData(dispatch, userId), // pass dispatch first: it's async
    loadOtherData(dispatch, userId) // pass dispatch first: it's async
  );
}


// component
componentWillMount() {
  loadAllData(this.props.dispatch, this.props.userId); // pass dispatch first
}

使用Redux Thunk动作创建者可以dispatch其他动作创建者的结果，甚至不会认为这些是同步还是异步：

// action creators
function loadSomeData(userId) {
  return dispatch => fetch(`http://data.com/${userId}`)
    .then(res => res.json())
    .then(
      data => dispatch({ type: 'LOAD_SOME_DATA_SUCCESS', data }),
      err => dispatch({ type: 'LOAD_SOME_DATA_FAILURE', err })
    );
}
function loadOtherData(userId) {
  return dispatch => fetch(`http://data.com/${userId}`)
    .then(res => res.json())
    .then(
      data => dispatch({ type: 'LOAD_OTHER_DATA_SUCCESS', data }),
      err => dispatch({ type: 'LOAD_OTHER_DATA_FAILURE', err })
    );
}
function loadAllData(userId) {
  return dispatch => Promise.all(
    dispatch(loadSomeData(userId)), // just dispatch normally!
    dispatch(loadOtherData(userId)) // just dispatch normally!
  );
}


// component
componentWillMount() {
  this.props.dispatch(loadAllData(this.props.userId)); // just dispatch normally!
}

使用这种方法，如果您以后希望您的动作创建者查看当前的Redux状态，您可以使用传递给thunk的第二个getState参数，而无需修改调用代码：

function loadSomeData(userId) {
  // Thanks to Redux Thunk I can use getState() here without changing callers
  return (dispatch, getState) => {
    if (getState().data[userId].isLoaded) {
      return Promise.resolve();
    }

    fetch(`http://data.com/${userId}`)
      .then(res => res.json())
      .then(
        data => dispatch({ type: 'LOAD_SOME_DATA_SUCCESS', data }),
        err => dispatch({ type: 'LOAD_SOME_DATA_FAILURE', err })
      );
  }
}

如果您需要将其更改为同步，您也可以在不更改任何调用代码的情况下执行此操作：

// I can change it to be a regular action creator without touching callers
function loadSomeData(userId) {
  return {
    type: 'LOAD_SOME_DATA_SUCCESS',
    data: localStorage.getItem('my-data')
  }
}

因此，使用Redux Thunk或Redux Promise等中间件的好处是组件不知道如何实现动作创建者，以及他们是否关心Redux状态，是同步还是异步，以及他们是否调用其他动作创作者。缺点是一点间接，但我们相信它在实际应用中是值得的。

最后，Redux Thunk和朋友只是Redux应用程序中异步请求的一种可能方法。另一个有趣的方法是Redux Saga，它允许您定义长时间运行的守护进程（“sagas”），这些守护进程在进行操作时执行操作，并在输出操作之前转换或执行请求。这将逻辑从动作创作者转变为传奇。您可能想要查看它，然后选择最适合您的内容。

  

我搜索了Redux回购中的线索，发现Action Creators过去必须是纯函数。

这是不正确的。文档说这个，但文档是错的。
行动创造者从未被要求成为纯粹的职能 我们修改了文档来反映这一点。

答案 1 :(得分：387)

你没有。

但是......你应该使用redux-saga：）

丹·阿布拉莫夫的回答是关于redux-thunk的，但我会更多地讨论redux-saga这个非常相似但更强大的内容。

命令式VS声明

  • DOM ：jQuery是必需的/ React是声明性的
  • Monads ：IO必不可少/免费声明
  • Redux效果：redux-thunk势在必行/ redux-saga是声明性的

当你手上有一个thunk，比如IO monad或promise时，你很难知道一旦你执行它会做什么。测试thunk的唯一方法是执行它，并模拟调度程序（如果它与更多东西交互，则模拟整个外部世界......）。

如果您使用的是模拟，那么您就不会进行函数式编程。

  

从副作用的镜头看，模拟是你的代码不纯的旗帜，在功能程序员的眼中，证明出现了问题。我们不应该下载图书馆以帮助我们检查冰山是否完整，而应该绕着它航行。   一个铁杆的TDD / Java人曾经问我如何在Clojure中进行模拟。答案是，我们通常不会。我们通常将其视为我们需要重构代码的标志。

Source

sagas（因为它们在redux-saga中实现）是声明性的，就像Free monad或React组件一样，它们更容易测试而不需要任何模拟。

另见article：

  在现代FP中，我们不应该编写程序 - 我们应该编写程序的描述，然后我们可以随意内省，转换和解释。

（实际上，Redux-saga就像一个混合体：流程势在必行，但效果是陈述性的）

混淆：动作/事件/命令......

前端世界有很多关于CQRS / EventSourcing和Flux / Redux等后端概念可能相关的混淆，主要是因为在Flux中我们使用术语＆＃34; action＆＃34;它有时代表命令式代码（LOAD_USER）和事件（USER_LOADED）。我相信，就像事件采购一样，你应该只发送事件。

在实践中使用传奇

想象一个带有用户个人资料链接的应用。使用这两个中间件处理此问题的惯用方法是：

redux-thunk 

<div onClick={e => dispatch(actions.loadUserProfile(123)}>Robert</div>

function loadUserProfile(userId) {
  return dispatch => fetch(`http://data.com/${userId}`)
    .then(res => res.json())
    .then(
      data => dispatch({ type: 'USER_PROFILE_LOADED', data }),
      err => dispatch({ type: 'USER_PROFILE_LOAD_FAILED', err })
    );
}

redux-saga 

<div onClick={e => dispatch({ type: 'USER_NAME_CLICKED', payload: 123 })}>Robert</div>


function* loadUserProfileOnNameClick() {
  yield* takeLatest("USER_NAME_CLICKED", fetchUser);
}

function* fetchUser(action) {
  try {
    const userProfile = yield fetch(`http://data.com/${action.payload.userId }`)
    yield put({ type: 'USER_PROFILE_LOADED', userProfile })
  } 
  catch(err) {
    yield put({ type: 'USER_PROFILE_LOAD_FAILED', err })
  }
}

此传奇转换为：

  

每次点击用户名时，都会获取用户个人资料，然后使用加载的个人资料调度事件。

如您所见，redux-saga有一些优势。

takeLatest的使用允许表示您只对获取上次用户名的数据感兴趣（如果用户在很多用户名上非常快速地点击，则处理并发问题）。这种东西很难用thunk。如果您不想要这种行为，可以使用takeEvery。

让动作创作者保持纯洁。请注意，保留actionCreators（在sagas put和组件dispatch中）仍然很有用，因为它可能会帮助您在将来添加操作验证（assertions / flow / typescript）。

由于效果是声明性的，您的代码变得更加可测试

您不再需要触发类似actions.loadUser()的类似rpc的通话。您的UI只需要发送已经发生的事情。我们只会触发事件（总是以过去时态！）而不再是行动。这意味着您可以创建解耦"ducks"或Bounded Contexts，并且saga可以充当这些模块化组件之间的耦合点。

这意味着您的观点更容易管理，因为他们不再需要在已发生的事件和应该发生的事件之间包含该翻译层

例如想象一个无限滚动视图。 CONTAINER_SCROLLED可以导致NEXT_PAGE_LOADED，但是可滚动容器的责任是决定我们是否应该加载另一个页面？然后他必须知道更复杂的事情，比如最后一页是否成功加载，或者是否已经有一个试图加载的页面，或者是否还有剩余的项目要加载？我不这么认为：为了获得最大的可重用性，可滚动容器应该只描述它已滚动。加载页面是一种商业效应＆＃34;那卷轴

有些人可能会争辩说，生成器可以使用局部变量固有地隐藏redux存储区之外的状态，但是如果你开始通过启动计时器等在thunk内部编排复杂的东西，那么无论如何都会遇到同样的问题。而select效果现在允许从Redux商店获得某些州。

Sagas可以进行时间旅行，还可以实现当前正在处理的复杂流量记录和开发工具。以下是一些已经实现的简单异步流日志：

saga flow logging

解耦

Sagas不仅取代了redux thunk。它们来自后端/分布式系统/事件源。

这是一个非常普遍的误解，传奇只是在这里以更好的可测试性取代你的redux thunk。实际上这只是redux-saga的一个实现细节。使用声明效果优于thunks的可测试性，但是saga模式可以在命令式或声明性代码之上实现。

首先，saga是一个软件，允许协调长时间运行的事务（最终的一致性），以及跨不同有界上下文的事务（域驱动设计术语）。

为了简化前端世界，假设有widget1和widget2。当单击widget1上的某个按钮时，它应该对widget2有影响。而不是将两个小部件耦合在一起（即widget1调度以widget2为目标的动作），widget1仅调度其按钮被单击。然后saga侦听此按钮单击，然后通过分析widget2知道的新事件来更新widget2。

这增加了简单应用程序不必要的间接级别，但可以更轻松地扩展复杂的应用程序。您现在可以将widget1和widget2发布到不同的npm存储库，这样他们就不必了解彼此，也不必共享全局的操作注册表。这两个小部件现在是有限的上下文，可以单独生活。他们不需要彼此保持一致，也可以在其他应用程序中重复使用。传奇是两个小部件之间的耦合点，它们以有意义的方式为您的业务协调它们。

关于如何构建Redux应用程序的一些很好的文章，你可以使用Redux-saga来解耦：

具体用例：通知系统

我希望我的组件能够触发应用内通知的显示。但我不希望我的组件高度耦合到具有自己的业务规则的通知系统（同时显示最多3个通知，通知排队，4秒显示时间等...）。

我不希望我的JSX组件决定何时显示/隐藏通知。我只是让它能够请求通知，并将复杂的规则留在传奇中。这种东西很难用thunks或promises来实现。

notifications

我已经描述了here如何使用saga

来完成此操作

为什么称它为传奇？

术语saga来自后端世界。我最初在long discussion中将Yassine（Redux-saga的作者）引入该术语。

最初，该术语是用paper引入的，传统模式应该用于处理分布式事务中的最终一致性，但是它的用法已经被后端开发人员扩展到更广泛的定义，所以现在它还包括＆＃34;流程经理＆＃34;模式（不知何故原始的传奇模式是流程管理器的一种特殊形式）。

今天，术语＆＃34; saga＆＃34;令人困惑，因为它可以描述两种不同的东西。正如它在redux-saga中使用的那样，它没有描述处理分布式事务的方法，而是一种协调应用程序中的操作的方法。 redux-saga也可以被称为redux-process-manager。

另见：

替代

如果您不喜欢使用生成器，但是您对saga模式及其解耦属性感兴趣，那么使用名称epic的{​​{3}}也可以实现相同的效果。描述完全相同的模式，但使用RxJS。如果您已经熟悉Rx，那么您会感到宾至如归。

const loadUserProfileOnNameClickEpic = action$ =>
  action$.ofType('USER_NAME_CLICKED')
    .switchMap(action =>
      Observable.ajax(`http://data.com/${action.payload.userId}`)
        .map(userProfile => ({
          type: 'USER_PROFILE_LOADED',
          userProfile
        }))
        .catch(err => Observable.of({
          type: 'USER_PROFILE_LOAD_FAILED',
          err
        }))
    );

一些redux-saga有用的资源

2017建议

  • 不要仅仅为了使用它而过度使用Redux-saga。可测试的API调用不值得。
  • 对于大多数简单案例，不要从项目中删除thunk。
  • 如果有意义的话，请不要在yield put(someActionThunk)发送任务。

如果您害怕使用Redux-saga（或Redux-observable）但只需要解耦模式，请检查Snake game implemented with Redux-saga：它允许侦听调度并在侦听器中触发新的调度。

const unsubscribe = store.addDispatchListener(action => {
  if (action.type === 'ping') {
    store.dispatch({ type: 'pong' });
  }
});

答案 2 :(得分：25)

简短的回答：对我来说，这似乎是一种非常合理的异步问题解决方法。有几个警告。

在我刚开始工作的新项目上，我有一个非常相似的想法。我非常喜欢vanilla Redux的优雅系统，用于更新商店和重新渲染组件，使其远离React组件树的内核。对我来说，使用优雅的dispatch机制来处理异步似乎很奇怪。

我最终采用了一种非常类似的方法来处理我在项目中所拥有的内容，我们将这个项目称为react-redux-controller。

由于以下几个原因，我最终没有采用上面的确切方法：

  1. 您编写的方式，这些调度功能无法访问商店。您可以通过让UI组件传递调度功能所需的所有信息来解决这个问题。但我认为这会将这些UI组件与调度逻辑不必要地耦合在一起。更有问题的是，调度功能没有明显的方式来访问异步延续中的更新状态。
  2. 调度功能可以通过词法范围访问dispatch。一旦connect语句失控，这就限制了重构的选项 - 并且仅使用一个update方法看起来非常笨拙。因此，如果将它们分解为单独的模块，您需要一些系统来让您编写这些调度程序功能。

    3. 总而言之，您必须安装一些系统以允许dispatch并将商店注入您的调度功能以及事件的参数。我知道这种依赖注入的三种合理方法：

    • redux-thunk通过将它们传递到你的thunks（通过圆顶定义使它们完全不是thunks），以功能性的方式做到这一点。我还没有使用其他dispatch中间件方法，但我认为它们基本相同。
    • react-redux-controller使用协程执行此操作。作为奖励，它还允许您访问＆＃34;选择器＆＃34;，这些函数可能作为connect的第一个参数传入，而不是直接使用原始函数，规范化商店。
    • 您也可以通过各种可能的机制将它们注入this上下文，从而实现面向对象的方式。

    <强>更新

    我觉得这个难题的一部分是react-redux的限制。 connect的第一个参数获取状态快照，但不是调度。第二个参数得到调度而不是状态。两个参数都没有得到关闭当前状态的thunk，因为能够在继续/回调时看到更新状态。

答案 3 :(得分：15)

Abramov的目标 - 理想情况下每个人 - 只是将封装在最合适的地方（和异步调用）。

在标准的Redux数据流中，哪里是最佳选择？怎么样：

  • <强>减速？没门。它们应该是纯粹的功能，没有副作用。更新商店是严肃，复杂的业务。不要污染它。
  • 哑视图组件？绝对不会。他们有一个问题：演示和用户互动，应该尽可能简单。
  • 容器组件？可能，但次优。有意义的是，容器是我们封装一些与视图相关的复杂性并与商店交互的地方，但是：
    • 容器确实需要比哑组件更复杂，但它仍然是一个单一的责任：提供视图和状态/存储之间的绑定。您的异步逻辑与此完全不同。
    • 通过将其放在容器中，您可以将异步逻辑锁定到单个上下文中，用于单个视图/路径。馊主意。理想情况下，它都是可重复使用的，并且完全分离。
  • S ome其他服务模块？错误的想法：您需要注入对商店的访问权限，这是一个可维护性/可测试性的噩梦。最好使用Redux并使用提供的API /模型访问商店。
  • 行动和解释它们的中间件？为什么不呢？！对于初学者来说，这是我们留下的唯一主要选择。 :-)更逻辑地说，动作系统是可以在任何地方使用的解耦执行逻辑。它可以访问商店并可以发送更多操作。它有一个单一的职责，即组织应用程序周围的控制和数据流，大多数异步适合于此。
    • 动作创作者怎么样？为什么不在那里做异步，而不是在动作本身和中间件？
      • 首先也是最重要的一点是，创建者无法访问商店，就像中间件一样。这意味着您无法发送新的或有行动，无法从商店读取以构成您的异步等。
      • 所以，要把复杂性放在一个复杂的必需品的地方，并保持其他一切都很简单。然后，创建者可以是简单，相对纯粹的功能，易于测试。

答案 4 :(得分：11)

回答开头提出的问题：

  

为什么容器组件无法调用异步API，然后调度操作？

请记住，这些文档适用于Redux，而不是Redux和React。 Redux商店连接到React组件可以完全按照您的意思行事，但没有中间件的Plain Jane Redux商店不接受dispatch的参数，除了普通的＆＃39;对象。

没有中间件你当然可以做

const store = createStore(reducer);
MyAPI.doThing().then(resp => store.dispatch(...));

但是，类似的情况是异步被围绕 Redux包裹，而不是由 Redux处理。因此，中间件通过修改可以直接传递给dispatch的内容来允许异步。

那就是说，我认为你的建议的精神是有效的。当然，还有其他方法可以在Redux + React应用程序中处理异步。

使用中间件的一个好处是，您可以继续正常使用动作创建者，而不必担心他们是如何连接的。例如，使用redux-thunk，您编写的代码看起来很像

function updateThing() {
  return dispatch => {
    dispatch({
      type: ActionTypes.STARTED_UPDATING
    });
    AsyncApi.getFieldValue()
      .then(result => dispatch({
        type: ActionTypes.UPDATED,
        payload: result
      }));
  }
}

const ConnectedApp = connect(
  (state) => { ...state },
  { update: updateThing }
)(App);

看起来与原作有什么不同 - 它只是拖了一下 - connect并不知道updateThing是（或需要异步。

如果您还想支持promises，observables，sagas或crazy custom和highly declarative动作创建者，那么Redux只需更改即可你传递给dispatch的东西（又名你从动作创作者那里归来的东西）。没有必要使用React组件（或connect调用）。

答案 5 :(得分：6)

好的，让我们开始看看中间件是如何工作的，这完全回答了这个问题，这是Redux中的 pplyMiddleWare 函数的源代码： / p> 

function applyMiddleware() {
  for (var _len = arguments.length, middlewares = Array(_len), _key = 0; _key < _len; _key++) {
    middlewares[_key] = arguments[_key];
  }

  return function (createStore) {
    return function (reducer, preloadedState, enhancer) {
      var store = createStore(reducer, preloadedState, enhancer);
      var _dispatch = store.dispatch;
      var chain = [];

      var middlewareAPI = {
        getState: store.getState,
        dispatch: function dispatch(action) {
          return _dispatch(action);
        }
      };
      chain = middlewares.map(function (middleware) {
        return middleware(middlewareAPI);
      });
      _dispatch = compose.apply(undefined, chain)(store.dispatch);

      return _extends({}, store, {
        dispatch: _dispatch
      });
    };
  };
}

查看此部分，了解我们的发送如何成为功能。

  ...
  getState: store.getState,
  dispatch: function dispatch(action) {
  return _dispatch(action);
}
  
      
  • 请注意，每个中间件都将被赋予dispatch和getState函数作为命名参数。
    •   

好的，这就是 Redux-thunk 作为Redux最常用的中间件之一：

  

Redux Thunk中间件允许您编写返回的动作创建者   一个函数而不是一个动作。 thunk可以用来延迟   发送行动，或仅在某种情况下发送   满足。内部函数接收存储方法dispatch和   getState作为参数。

如你所见，它将返回一个函数而不是一个动作，这意味着你可以随时随地调用它，因为它是一个函数......

那真是太糟糕了？它是如何在维基百科中引入的：

  

在计算机编程中，thunk是用于注入的子程序   另外计算到另一个子程序。 Thunk主要是   用于延迟计算直到需要或插入   在另一个子程序的开头或结尾处的操作。他们有   各种其他应用程序，以编译代码生成和   模块化编程。

     

该术语起源于＆＃34;思考＆＃34;。

的jocular衍生物      

thunk是一个包装表达式以延迟它的函数   评价。

//calculation of 1 + 2 is immediate 
//x === 3 
let x = 1 + 2;

//calculation of 1 + 2 is delayed 
//foo can be called later to perform the calculation 
//foo is a thunk! 
let foo = () => 1 + 2;

请注意概念是多么容易以及它如何帮助您管理异步操作......

没有它你就能活下去，但在编程中要记住，总有更好，更整洁，更恰当的方式做事......

Apply middleware Redux

答案 6 :(得分：3)

在企业项目中工作时，中间件有很多要求，例如（saga）在简单的异步流程中不可用，以下是一些要求：

  • 并行
    • 中的运行请求
  • 无需等待即可拉动将来的动作
  • 无阻塞通话竞赛效果，首先是示例接听
  • 响应以启动对任务进行排序的过程（第一次调用）
  • 撰写
  • 任务取消动态分叉任务。
  • 支持在Redux中间件外部运行Saga。
  • 使用频道

列表很长，只需查看saga documentation的高级部分

答案 7 :(得分：2)

使用Redux-saga是React-redux实现中最好的中间件。

例：      store.js 

  import createSagaMiddleware from 'redux-saga';
  import { createStore, applyMiddleware } from 'redux';
  import allReducer from '../reducer/allReducer';
  import rootSaga from '../saga';

  const sagaMiddleware = createSagaMiddleware();
  const store = createStore(
     allReducer,
     applyMiddleware(sagaMiddleware)
   )

   sagaMiddleware.run(rootSaga);

 export default store;

然后是saga.js 

import {takeLatest,delay} from 'redux-saga';
import {call, put, take, select} from 'redux-saga/effects';
import { push } from 'react-router-redux';
import data from './data.json';

export function* updateLesson(){
   try{
       yield put({type:'INITIAL_DATA',payload:data}) // initial data from json
       yield* takeLatest('UPDATE_DETAIL',updateDetail) // listen to your action.js 
   }
   catch(e){
      console.log("error",e)
     }
  }

export function* updateDetail(action) {
  try{
       //To write store update details
   }  
    catch(e){
       console.log("error",e)
    } 
 }

export default function* rootSaga(){
    yield [
        updateLesson()
       ]
    }

然后是action.js 

 export default function updateFruit(props,fruit) {
    return (
       {
         type:"UPDATE_DETAIL",
         payload:fruit,
         props:props
       }
     )
  }

然后是reducer.js 

import {combineReducers} from 'redux';

const fetchInitialData = (state=[],action) => {
    switch(action.type){
      case "INITIAL_DATA":
          return ({type:action.type, payload:action.payload});
          break;
      }
     return state;
  }
 const updateDetailsData = (state=[],action) => {
    switch(action.type){
      case "INITIAL_DATA":
          return ({type:action.type, payload:action.payload});
          break;
      }
     return state;
  }
const allReducers =combineReducers({
   data:fetchInitialData,
   updateDetailsData
 })
export default allReducers;

然后是main.js 

import React from 'react';
import ReactDOM from 'react-dom';
import App from './app/components/App.jsx';
import {Provider} from 'react-redux';
import store from './app/store';
import createRoutes from './app/routes';

const initialState = {};
const store = configureStore(initialState, browserHistory);

ReactDOM.render(
       <Provider store={store}>
          <App />  /*is your Component*/
       </Provider>, 
document.getElementById('app'));

试试这个..正在运作

答案 8 :(得分：1)

回答问题：

  

为什么容器组件不能调用异步API，然后   派遣行动？

我之所以这样说至少有两个原因：

第一个原因是关注点分离，调用action creator并取回数据不是api的工作，您必须将两个参数传递给{{1} }，action creator function和action type。

第二个原因是因为payload正在等待具有强制操作类型和可选的redux store的普通对象（但在这里您也必须传递有效负载）。

动作创建者应该是一个普通的对象，如下所示：

payload

然后function addTodo(text) { return { type: ADD_TODO, text } } 到Redux-Thunk midleware的工作将您的dispache的结果转换为适当的api call。

答案 9 :(得分：0)

有同步动作创建者，然后有异步动作创建者。

一个同步动作创建者是这样的，当我们调用它时，它会立即返回一个Action对象，并将所有相关数据附加到该对象上，并准备由我们的reducer处理。

异步动作创建者需要花费一些时间才能准备好分派动作。

根据定义，只要您有一个动作创建者发出网络请求，它就总是有资格作为异步动作创建者。

如果要在Redux应用程序中包含异步操作创建者，则必须安装称为中间件的东西，该中间件将允许您处理这些异步操作创建者。

您可以在错误消息中对此进行验证，该错误消息告诉我们使用自定义中间件进行异步操作。

那么什么是中间件？为什么在Redux中我们需要它来进行异步流程？

在redux中间件（例如redux-thunk）的上下文中，中间件可帮助我们处理异步操作创建者，因为Redux无法开箱即用。

在Redux周期中集成了中间件后，我们仍在调用动作创建者，这将返回将要分派的动作，但是现在当我们分派动作时，而不是直接将其发送给所有的reducer，我们要说的是，动作将通过应用程序内的所有不同中间件发送。

在单个Redux应用程序内，我们可以拥有任意数量的中间件。在大多数情况下，在我们从事的项目中，我们将在Redux商店中连接一个或两个中间件。

中间件是普通的JavaScript函数，将在我们分派的每个操作中调用该中间件。在该功能的内部，中间件有机会阻止将操作分派到任何化简器，它可以以任何方式修改操作或以某种方式摆弄一个操作，例如，我们可以创建一个控制台日志的中间件您派发的每一个动作只是为了您的观看乐趣。

您可以将大量的开源中间件作为依赖项安装到项目中。

您不仅限于仅使用开源中间件或将它们安装为依赖项。您可以编写自己的自定义中间件，然后在Redux商店中使用它。

中间件更流行的用途之一（并得到答案）是与异步操作创建者打交道，可能最流行的中间件是redux-thunk，它是帮助您与异步操作创建者打交道。 / p>

还有许多其他类型的中间件也可以帮助您与异步操作创建者打交道。

答案 10 :(得分：0)

Redux不能返回函数而不是动作。这只是事实。这就是人们使用Thunk的原因。阅读以下14行代码，以了解它如何使异步周期与某些添加的功能分层一起工作：

function createThunkMiddleware(extraArgument) {
  return ({ dispatch, getState }) => (next) => (action) => {
    if (typeof action === 'function') {
      return action(dispatch, getState, extraArgument);
    }

    return next(action);
  };
}

const thunk = createThunkMiddleware();
thunk.withExtraArgument = createThunkMiddleware;

export default thunk;

https://github.com/reduxjs/redux-thunk

相关问题
最新问题