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