我正在使用Redux来管理音乐播放器的逻辑。当它正在播放某些内容并突然失败时，我希望能够拦截该动作并使播放器重新开始，但只能进行n次，因为我不想在问题不存在的情况下永远自动重试可恢复的。
我认为中间件是实现此目的的不错选择，但是我想知道是否应该在全局状态下或在中间件中存储针对某个项目已经进行的重试次数。
一个更笼统的问题是，Redux中间件是否应该完全包含任何本地状态，我的意思是说，仅它关心的状态。
答案 0 :(得分：1)
我认为（并基于有关您特定项目的有限信息）：
n值，并且n和totalRetries都存储在中间件的私有变量中。为什么？
选择将中间件状态存储在何处与deciding between component state and redux state有相似之处。您可以使用与指南相同的问题：
- 应用程序的其他部分是否关心此数据？
- 您是否需要能够基于此原始数据创建其他派生数据？
- 是否使用相同的数据来驱动多个组件？
- 能够将状态恢复到给定的时间点（例如，时间旅行调试）对您有价值吗？
- 您是否要缓存数据（即，使用已存在的状态而不是重新请求）？
- 您是否要在热重载UI组件时保持这些数据的一致性（交换时可能会丢失其内部状态）？
如丹·阿布拉莫夫所说：
我对它进行分类的方式是，当状态需要由多个组件或多个页面共享，并且我们需要在路由更改时保留一些数据时，所有这些数据都应存储在redux存储中。
您可以通过将“ …通过路由更改保留一些数据……”改为“ …通过[在此处插入相关边界]保留一些数据……”来将这种想法从组件映射到中间件。”，例如关闭并重新启动该应用。
totalRetries似乎并不代表应用程序的有意义状态。它与某些“幕后” I / O操作有关，该操作在关闭应用程序或与调试器共享应用程序状态时不会持续存在。甚至可能会争辩说，您不应通过redux状态将其公开给其他组件，以免它们依赖（可能转移）中间件的内部工作。
redux-saga等使我们能够以非常整洁和可测试的方式编写此类功能，而无需在应用程序状态或模块名称空间中使用“暴露的电线”。您可以使用传奇来封装您的整个“播放音频”行为。
导出Reducer，然后从中间件访问其分隔的“ public”状态会引入很多不必要的复杂性。
如果您想要将totalRetries和n暴露给其他组件，则可以通过诸如PLAY_AUDIO_RETRY之类的操作来实现。在其有效负载中包含两个变量的操作。