我遇到了有趣的文章（帖子末尾的链接） . 该文章的作者指出，他们将redux存储区视为客户端数据库，并且UI逻辑不适合那里（如果不相关的组件不需要），即使是为了数据获取目的 . 例如，我们想在获取一些数据时显示一些加载微调器：
async componentDidMount() {
this.setState({isLoading: true});
await this.props.fetchSomeData();
this.setState({isLoading: false});
}
我们触发异步thunk动作，该动作获取多个组件所需的一些数据，或者我们想要缓存该数据，即使卸载该组件也是如此 .
关注加载状态的唯一组件是我们触发thunk动作的组件，其他组件不关心加载状态 . 但是我总是看到带有异步动作创建器的redux示例，它们会激活REQUEST / SUCCESS / FAILURE动作类型和减少器，即使它们在一个组件中使用，也会加载状态 .
我可以看到这些代码的一些缺点，一些状态存在于组件中，一些存在于redux中，但优点是redux存储不会因其他组件不需要的状态而膨胀，我们也可以避免redux的冗长 .
所以我的问题是，对于这个特定的例子，这种状态分离的缺点是什么？
文章：https://dev.bleacherreport.com/3-things-i-learned-about-working-with-data-in-redux-5fa0d5f89c8b（文章评论中也有趣的讨论）
1 回答
国际海事组织，你的州分离方法的一些缺点是：
如果场景后面有复杂的API获取（获取A然后获取B然后获取C）
redux-thunk将是不够的，您将不得不使用redux-saga或redux-observable以及它们，REQUEST / SUCCESS / FAILURE样式 .如果将来有其他组件需要监听'加载'状态或者更糟糕需要相同的数据但是不能保证显示它们的顺序是相同的（A挂载和获取数据然后B在获取数据之前安装，再次获取B），您将不得不重构所有结构 . 当你需要取消获取时，这不算数 .
如果在获取数据之前卸载组件，则“this.setState”调用将导致空引用错误 .
一般情况下，我同意UI状态应放在组件中，但全局状态必须始终存储在Redux存储中，并且
isLoading不完全是UI状态，而是组件正在侦听的请求的状态 .