我试图找出解决这个问题的惯用方法：
我有一个包含“应用过滤器”列表和“记录”列表的化简器。当我更改过滤器或记录时，“过滤记录”列表也应该更改，但是将过滤器应用于可能很长的记录列表可能会很慢。
现在，我正在发送“添加过滤器”或“删除过滤器”操作来更改“应用过滤器”列表。这导致重新计算“过滤记录”列表（当前在 reducer 中完成）。
我正在使用两个容器组件，一个显示“过滤芯片”列表，另一个显示“过滤记录”列表。
因为应用过滤器需要一段时间，并且每次过滤器更改时都会完成，所以从 UI 中删除过滤器的过程似乎很滞后——我单击删除过滤器，并且删除的过滤器不会消失，直到 reducer 完成所有它的工作，包括更新过滤器列表和应用新的过滤器列表。
我宁愿拥有的是：
- 删除过滤器，它会尽快从 UI 中消失。（即，广播状态更改仅包含已删除的过滤器）
- 同时，我希望应用过滤器的过程发生在后台，一旦完成，调度另一个操作来更改过滤记录列表。
- 在应用过滤器并触发更新过滤记录的操作后，我希望更新“过滤记录列表”组件。
因此，基本上我希望状态更改可能触发另一个状态更改，但我想在这两个状态更改之间广播中间状态。
我知道我必须从我的减速器中取出庞大的逻辑并投入到一个动作中，但我正在为应该如何/在哪里应用该逻辑而苦苦挣扎。我有一种唠叨的感觉，我已经把我的大脑缠绕在它的轴上，我现在把事情复杂化了，但我似乎无法回到简单/正确的方法。
任何帮助将不胜感激！
编辑，来自我添加的评论，但也想在这里保持内联：
我在最初的问题中说错了，在这里进行了很大的更正-
我实际上并没有计算减速器中的“过滤记录列表”——我的“RecordList”容器上有一个重新选择选择器，它接收“记录”和“过滤器”并返回过滤记录的列表。
我认为这更多是因为“RecordList”渲染阻止了“FilterList”渲染，所以我要向上组件层次结构，看看我是否可以在那里修复一些东西。
不过，我仍然愿意提出任何建议！