阿布拉莫夫的目标（也是每个人的理想目标）只是将复杂性（和异步调用）封装在最合适和可重用的地方。

在标准的Redux数据流中，哪里是最好的地方？怎么样：

减速器？不可能。它们应该是没有副作用的纯函数。更新商店是一项严肃而复杂的业务。不要污染它。哑视图组件？肯定不会。他们有一个问题：演示和用户交互，并且应该尽可能简单。容器组件？可能，但次优。这是有意义的，因为容器是我们封装一些视图相关复杂性并与存储交互的地方，但是：容器确实需要比哑组件更复杂，但它仍然是一个单一的责任：在视图和状态/存储之间提供绑定。您的异步逻辑与此完全不同。通过将其放置在容器中，可以将异步逻辑锁定到一个上下文中，并与一个或多个视图/路由相耦合。坏主意。理想情况下，它都是可重用的，并且与视图完全分离。（与所有规则一样，如果您有状态绑定逻辑，恰好可以在多个上下文中重用，或者您可以以某种方式将所有状态概括为集成的GraphQL模式，则可能会出现异常。好吧，很好，这可能很酷。但……大多数时候，绑定似乎都是上下文/视图特定的。）其他服务模块？坏主意：您需要注入对存储的访问，这是一个可维护性/可测试性噩梦。最好使用Redux的颗粒，只使用提供的API/模型访问商店。动作和解释它们的中间件？为什么不呢？首先，这是我们剩下的唯一主要选择从逻辑上讲，操作系统是解耦的执行逻辑，您可以在任何地方使用它。它可以访问商店，并可以调度更多操作。它有一个单一的职责，即组织应用程序周围的控制和数据流，而大多数异步正好适合这一点。动作创造者呢？为什么不在那里做异步，而不是在操作本身和中间件中？首先，也是最重要的一点，创建者不能像中间件那样访问存储。这意味着你不能分派新的临时动作，不能从存储中读取以组成异步等等。所以，把复杂性放在一个必要性复杂的地方，把其他一切都保持简单。然后，创建者可以是简单的、相对简单的、易于测试的函数。

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

前任：商店.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'));

试试这个。。正在工作

阿布拉莫夫的目标（也是每个人的理想目标）只是将复杂性（和异步调用）封装在最合适和可重用的地方。

在标准的Redux数据流中，哪里是最好的地方？怎么样：

减速器？不可能。它们应该是没有副作用的纯函数。更新商店是一项严肃而复杂的业务。不要污染它。哑视图组件？肯定不会。他们有一个问题：演示和用户交互，并且应该尽可能简单。容器组件？可能，但次优。这是有意义的，因为容器是我们封装一些视图相关复杂性并与存储交互的地方，但是：容器确实需要比哑组件更复杂，但它仍然是一个单一的责任：在视图和状态/存储之间提供绑定。您的异步逻辑与此完全不同。通过将其放置在容器中，可以将异步逻辑锁定到一个上下文中，并与一个或多个视图/路由相耦合。坏主意。理想情况下，它都是可重用的，并且与视图完全分离。（与所有规则一样，如果您有状态绑定逻辑，恰好可以在多个上下文中重用，或者您可以以某种方式将所有状态概括为集成的GraphQL模式，则可能会出现异常。好吧，很好，这可能很酷。但……大多数时候，绑定似乎都是上下文/视图特定的。）其他服务模块？坏主意：您需要注入对存储的访问，这是一个可维护性/可测试性噩梦。最好使用Redux的颗粒，只使用提供的API/模型访问商店。动作和解释它们的中间件？为什么不呢？首先，这是我们剩下的唯一主要选择从逻辑上讲，操作系统是解耦的执行逻辑，您可以在任何地方使用它。它可以访问商店，并可以调度更多操作。它有一个单一的职责，即组织应用程序周围的控制和数据流，而大多数异步正好适合这一点。动作创造者呢？为什么不在那里做异步，而不是在操作本身和中间件中？首先，也是最重要的一点，创建者不能像中间件那样访问存储。这意味着你不能分派新的临时动作，不能从存储中读取以组成异步等等。所以，把复杂性放在一个必要性复杂的地方，把其他一切都保持简单。然后，创建者可以是简单的、相对简单的、易于测试的函数。

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

同步动作创建器是一个当我们调用它时，它会立即返回一个action对象，其中包含附加到该对象的所有相关数据，并准备好由我们的还原器处理。

异步动作创建器需要一点时间才能最终调度动作。

根据定义，每当您有一个动作创建者发出网络请求时，它总是符合异步动作创建者的资格。

如果您想在Redux应用程序中使用异步动作创建器，则必须安装一种叫做中间件的东西，该中间件将允许您处理这些异步动作创建。

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

那么什么是中间件，为什么我们需要它来实现Redux中的异步流呢？

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

随着中间件集成到Redux循环中，我们仍在调用动作创建者，这将返回一个将被调度的动作，但现在，当我们调度一个动作时，而不是直接将其发送给所有的reducer，我们将说一个动作将通过应用程序中的所有不同中间件发送。

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

中间件是一个普通的JavaScript函数，我们分派的每个动作都会调用它。在该功能内部，中间件有机会阻止某个动作被分派到任何一个reducer，它可以修改某个动作或以任何方式处理某个动作，例如，我们可以创建一个中间件，控制台记录您分派的每一个动作，只是为了您的观看乐趣。

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

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

中间件的一个更流行的用途（并得到您的答案）是处理异步动作创建者，可能最流行的中间件是redux thunk，它是帮助您处理异步动作创作者。

还有许多其他类型的中间件也可以帮助您处理异步动作创建者。

简短的回答：对我来说，这似乎是解决异步问题的一种完全合理的方法。

当我在一个新项目上工作时，我有一个非常相似的想法，我们刚刚开始我的工作。我是vanilla Redux优雅系统的忠实粉丝，该系统可以更新商店并以一种远离React组件树的方式重新渲染组件。在我看来，使用这种优雅的调度机制来处理异步似乎很奇怪。

我最终采用了一种非常类似的方法，就像我从项目中分解出来的一个库一样，我们称之为react redux控制器。

出于以下几个原因，我最终没有采用上述方法：

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

总之，您必须装配一些系统，以便将调度和存储以及事件的参数注入到调度函数中。我知道三种合理的依赖注入方法：

redux thunk通过将它们传递给你的thunk（根据dome定义，使它们完全不是thunk），以一种功能性的方式实现了这一点。我还没有使用过其他调度中间件方法，但我认为它们基本相同。react-redux控制器通过协程实现这一点。另外，它还允许您访问“选择器”，这些函数可能是您作为连接的第一个参数传入的，而不必直接使用原始的标准化存储。您还可以通过各种可能的机制将它们注入到这个上下文中，以面向对象的方式来实现这一点。

使现代化

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

要回答开头提出的问题：

为什么容器组件不能调用异步API，然后分派操作？

请记住，这些文档适用于Redux，而不是Redux+React。连接到React组件的Redux商店可以做到您所说的一切，但没有中间件的Plain Jane Redux商店不接受除普通对象之外的参数来分派。

如果没有中间件，你当然还可以

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

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

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

使用中间件的一个好处是，您可以继续正常使用动作创建者，而不必担心它们是如何连接的。例如，使用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是（或需要）异步的。

如果您还想支持承诺、可观测性、传奇或疯狂的自定义和高度声明性的动作创建者，那么Redux可以通过更改传递给分派的内容（也就是从动作创建者返回的内容）来实现。无需干扰React组件（或连接调用）。