通量存储或动作（或两者）是否应该涉及外部服务？

我已经看到了两种方式都实现了通量模式，并且我自己都做完之后（最初采用了前一种方法），我认为存储应该是动作中数据的愚蠢接收者，并且异步处理写操作应该存在于动作创作者。（异步读取的处理方式可能有所不同。）以我的经验，按重要性顺序，它有一些好处：

1. 您的商店将完全同步。 这使您的商店逻辑更易于遵循和测试，非常容易-只需使用某种给定状态实例化商店，向其发送操作，然后检查状态是否按预期更改。此外，流量中的核心概念之一是防止级联调度并一次阻止多个调度。当商店进行异步处理时，这很难做到。

2. 所有动作分派均由动作创建者执行。 如果您在商店中处理异步操作，并且希望使商店的动作处理程序保持同步（并且应该为了获得通量单次派发保证），则商店将需要触发其他SUCCESS和FAIL动作以响应异步处理。相反，将这些调度放到动作创建者中有助于将动作创建者和商店的工作分开；此外，您不必深入研究商店逻辑即可确定从何处调度操作。在这种情况下，典型的异步操作可能看起来像这样（

   dispatch

   根据您使用的助焊剂的风味更改调用的语法）：

        someActionCreator: function(userId) {      // Dispatch an action now so that stores that want      // to optimistically update their state can do so.      dispatch("SOME_ACTION", {userId: userId});      // This example uses promises, but you can use Node-style      // callbacks or whatever you want for error handling.      SomeDataAccessLayer.doSomething(userId)      .then(function(newData) {        // Stores that optimistically updated may not do anything        // with a "SUCCESS" action, but you might e.g. stop showing        // a loading indicator, etc.        dispatch("SOME_ACTION_SUCCESS", {userId: userId, newdata: newData});      }, function(error) {        // Stores can roll back by watching for the error case.        dispatch("SOME_ACTION_FAIL", {userId: userId, error: error});      });    }

否则可能会在各种动作之间重复的逻辑应提取到单独的模块中；在此示例中，该模块将是

SomeDataAccessLayer

1. 您需要较少的动作创建者。 这没什么大不了的，但是很高兴。如＃2所述，如果您的商店具有同步操作分派处理（并且应该这样做），则需要触发额外的操作来处理异步操作的结果。在动作创建者中进行分派意味着单个动作创建者可以通过处理异步数据访问本身的结果来分派所有三种动作类型。