我有一个传奇，它每 10 秒在 POLL 操作上运行一次，以更新我的 GUI 上的当前状态。
当发生 POLL 时，我需要打几个电话来沿着 rest 界面向下走，以找到我关心的组件。 总共将有 1-5 个组件，对于每个组件，我需要对组件的 Foo 和 Bar 元素进行单独的休息调用。
然后在某些时候，我需要做一些求和，将 Foo 和 Bar 数据组合在一起，以获得我的表所期望的结构来列出组件，计算仪表板中所有组件的一些总计等。 没有一项工作是 CPU 密集型的，但它加起来有相当多的代码，因为我有很多东西需要调整。
目前，我在Saga中做所有这些工作，但我不确定这是否被认为是不好的做法？ 我觉得化简器是数据调整的一般"去"地方，但是用如此大的有效载荷抛出一个动作感觉很奇怪，传奇中每个调用的所有响应，因为其余的大部分响应都是我不关心的数据。 我也喜欢在 saga 中进行所有处理，这样我就可以在一切结束时做出决定，而不是传递错误操作以向用户显示错误或通过成功操作来清除任何以前的错误，一些决定是我想清除操作需要更多数据处理。
我唯一担心的是生成器变得相当大，有很多辅助方法在 saga 类中感觉有点不合适来处理(无论我怎么想，它们都需要移动到 utils 类)。 处理不是太昂贵，而且我使用的是生成器，所以我认为处理不会对 saga 的"线程"产生明显影响。 不过，如果有推荐的最佳实践，我想坚持下去。 我是否打破了对传奇中的数据进行所有调整的标准做法，并将每个格式的对象发送到化简器，使其无需任何其他处理即可存储到状态中？
这实际上是一个常见问题的特定情况，由 Redux FAQ 关于"我的业务逻辑应该驻扎在哪里？"解决。 引用这个答案：
现在，问题是在动作创建器中放置什么，在减速器中放入什么，在胖动作对象和瘦动作对象之间进行选择。如果将所有逻辑放在操作创建器中，则最终会得到胖操作对象，这些对象基本上声明了状态的更新。化简器变得纯粹，愚蠢，添加这个，删除那个，更新这些功能。它们将很容易组成。但是，您的业务逻辑不会太多。如果你在化简器中放更多的逻辑，你最终会得到漂亮、精简的动作对象，你的大部分数据逻辑都在一个地方，但你的化简器更难组合，因为你可能需要来自其他分支的信息。你最终会得到大型化简器或化简器，这些化简器从州内上层获取额外的参数。
在"动作创建"端(无论是在组件、thunks、saga 还是中间件中)拥有逻辑来做大量工作来准备和格式化数据并没有错，而让化简器简单地存储动作中包含的内容。 另一方面，在化简器端拥有更多逻辑可能意味着时间旅行调试将重新运行更多实际代码，从而为您提供更多编辑和重试行为的机会。
总的来说，听起来你正在做的事情是完全合理的。