React 中实现基于事件的模式(发布者/订阅者)的最新技术是什么。
从一方面来看，我们有监听这些事件的组件。其中一些组件是视觉的，例如绘制查询结果的图表其他可能不直观，例如如果我们想要拥有管理查询和结果的组件。
相对而言，任何组件都可以生成事件。
我们的第一个想法是在 Redux 中添加事件及其值的完整列表，并在每个组件上实现 shouldComponentUpdate() 中的智能代码，如果组件不监听更改的事件，该代码就会停止。
这看起来不太优雅，因为所有组件都会监听所有事件。是否有更优雅的解决方案(某种最先进的解决方案)？
当然，我们希望能够后退、前进、保存状态以及所有这些小细节:-)
最佳答案
我认为你需要了解的并不是“最先进的技术是什么”，而是“使用 React 和 Redux 进行发布和订阅的规范方式是什么”。
简短的回答是，如果您有一个足够复杂的应用程序，您应该组织您的商店，以便应用程序状态分为 slices并使用 container pattern将发布和订阅的责任分开。这样您就可以避免您提到的问题，即您不知道代码库中的哪些内容正在更改存储以及哪些内容正在响应这些更改。您可以查看容器组件并了解它如何处理来自其子组件的 UI 事件并生成状态更改事件。或者您可以查看容器如何处理状态更改，然后向下钻取层次结构。如果您可以让 Redux 切片承担单个容器的责任，那么考虑事件就会容易得多。所有其他组件本身并不订阅事件，而是从源自容器组件的 props 接收渲染所需的更改。它们通过 props 传递下来的回调通知容器组件自己的事件，以便容器可以发布它们。这可能会走很长很长的路，如果您觉得需要传递太多级别的 props，您可以使用 React.children 来稍微扁平化嵌套，或者在极少数情况下使用上下文。
较长的答案有点困难，因为在谈论 React 时发布和订阅并不是非常有意义。 React 最终应该负责渲染。正如您提到的，并非所有事件都是 UI 事件。但是，如果您对事物进行建模，以便您可以发布和订阅的所有事件都归结为更改商店或对商店更改使用react，那么您可以构建更多专注于 Redux 的应用程序。管理您正在讨论的查询和结果应该在简单的 JavaScript 模块中完成，而不需要 React。然后，您可以使用容器组件将商店粘合到该模块。
人们还使用其他模式，例如操作创建者和选择器。这些都很好，因为至少其目的是让代码库保持熟悉。但事情的进展仍然有点快，React 正在朝着 Hooks API 方向发展。和 React-Redux trying to catch-up 。但切片和容器组件不会消失，它们是分离关注点的自然方式。
关于reactjs - react /Redux : Events - state of the art，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/54762190/