在我看来，趋势是用React Context API和useReducer代替Redux。
我个人不喜欢从用户数据状态到是否打开对话框都混在一起的根源存储。
切换到React Context API使我可以将状态向下推并更接近将使用它们的位置。但是，我只能将其下推到子组件正在显示或修改该值的级别。例如：
<Parent>
<CounterDisplay/>
<CounterIncreaseButton/>
</Parent>
我必须依靠父级并创建上下文。在上下文中，我将添加计数值和一个count方法（或使用reducer模式时的状态和调度函数）。然后，我为这两个子组件提供了上下文。现在，可以显示它，而可以对其进行修改。
现在，如果我需要一个距离组件树这一部分较远的按钮，又需要更改计数值，该怎么办？我必须提起状态，甚至一直提起根源。我觉得这很奇怪。
第二个问题是，当状态沿着树中的路径分散在多个级别上时，当发生某些情况（例如用户单击按钮）时，您可能需要从多个上下文中调用多个函数（或调度多个操作，每个状态可能会针对每个状态或可能不会改变）。与使用Redux时不同，因为一切都从根开始，您只需要调度一个动作。
那么，如果我在根目录下有一个事件发布/订阅怎么办？我可以拥有计数器状态，并通过代码操作将其进一步下推到CounterDisplay。 CounterDisplay需要订阅发布/订阅系统并收听事件并相应地更新计数器。无论哪个组件想要更改计数器，都可以引发一个事件。
我在这种模式下缺少什么？循环事件循环？养育条件？感觉良好的发布/订阅库可以防止这些情况。我环顾四周，没有发现任何东西。我看着RxJS，但感觉不合适。
感谢您分享您的想法。
您基本上已经描述了Redux存在的确切原因：）
Redux is“根目录下的事件发布/订阅”，在需要广泛分离的组件需要使用相同数据的情况下特别有利。
[您可能需要阅读我的文章Redux - Not Dead Yet!，其中描述了Redux如何适应当今的生态系统（包括比较与环境），以及一些可能有用的原因。
如果您因样板的数量而无法使用redux。我建议您看看redux-zero。
引擎盖下。 react-redux在根目录使用上下文提供程序。当您使用正在使用connect的context高阶组件时。与redux挂钩相同。
因此，将提供者放在顶部是很正常的。对于像react-router这样的任何库，都将相同。
我建议您继续尝试不使用redux，以便您了解更多。将提供者放在根上。无论如何它都不会影响性能。将您创建的上下文和提供程序隔离到一个单例文件中，并将其导入到所需的组件中