我在网上看到人们有类似事件的例子，他们通过组件本身的函数调用来处理它们然后直接通过执行基本的事情来改变状态：
saveCourse(event) {
this.setState({saving: true});
}
我曾经想过，在使用react-redux时，根据动作调用在减速器中进行所有状态更改非常重要。
如果我以某种方式错过了react-redux的常用模式，请告诉我。
继续使用React自己的State机制与Redux商店一起完全没问题。
以下是我如何理解这两个选择：如果一个数据（以及发生的变化）是单个组件及其直接子组件的本地数据，请使用State。像往常一样使用React更新它。
如果要在整个应用程序中使用一段数据，在可能存在或不存在于同一组件树中的各种组件中，或者可能通过各种中间组件将它们彼此分开，那么请使用Redux，这样就不会结束向上和向下传递道具和处理程序回调。
这里有一个例子来说明这一点：想象一下，你的Redux商店里有一个联系人列表。和addContact reducer一起添加一个新的联系人列表。此列表中的项目可能会在您的应用程序中以各种形状和位置显示。例如，侧栏上的菜单项可以显示列表上的项目数，而主面板中的另一个div可以列出项目及其详细信息。到目前为止都很好。
现在，您需要创建一个NewContact组件，该组件呈现表单和必要的输入字段，以便用户将新联系人添加到列表中。此表单上的输入可以是Controlled Components，更新NewContact组件的内部状态，完全绕过Redux存储。在表单提交后，您的组件将使用适当的有效负载调度addNewContact操作，此时新联系人将通过Redux机制添加到列表中，并将必要的更新传播到应用程序的其余部分。
这是同时混合使用Redux Store和React State的有效示例。
现在，您是否可以在Redux中管理NewContact表单的状态？ Absolutely！不过你呢？你的来电。你不必这样做，除非这样做有一些好处。
在redux中管理状态并不意味着你不能使用有状态组件作出反应，你主要使用setState来重新渲染组件并接收新的道具。虽然我，我使用this.forceUpdate重新渲染。但设置状态似乎更好
setState正在改变本地组件的状态，如果您要更改的范围仅在您的组件本地而不是您的应用程序中，则更改本地状态没有任何问题。对于前者显示/隐藏模态，或更改某些UI元素，如果您重新加载页面，该元素将不会持久存在，例如打开/关闭下拉列表。