Question

React实现基于事件的模式（发布者/订阅者）的最新技术水平。

从一侧看，我们有侦听这些事件的组件。这些组件中的一些是可视的，例如绘制查询结果的图表可能不可见，例如如果我们想拥有管理查询和结果的组件。

另一方面，任何组件都可以生成事件。

我们的第一个想法是在Redux中添加事件及其值的完整列表，并在shouldComponentUpdate（）的每个组件实现上添加一个智能代码，如果该组件不侦听更改的事件，该代码将停止。

这看起来不太优雅，因为所有组件都监听所有事件。是否有更优雅的解决方案（最先进的技术）？

我们当然希望能够回去，进行战争，保存状态以及所有这些小细节:-)

Answer 1

redux存储事件重新选择/连接以订阅它们（https://github.com/reduxjs/reselect#connecting-a-selector-to-the-redux-store）

import { connect } from 'react-redux'
import { toggleTodo } from '../actions'
import TodoList from '../components/TodoList'
import { getVisibleTodos } from '../selectors'

const mapStateToProps = (state) => {
  return {
    todos: getVisibleTodos(state)
  }
}

const mapDispatchToProps = (dispatch) => {
  return {
    onTodoClick: (id) => {
      dispatch(toggleTodo(id))
    }
  }
}

const VisibleTodoList = connect(
  mapStateToProps,
  mapDispatchToProps
)(TodoList)

export default VisibleTodoList

现在，您已将订阅的事件作为道具放置在组件中，仅当道具发生更改时，组件才会重新渲染。不需要shouldComponentUpdate，因为您的组件不必侦听整个商店，它将只获取您在选择器中定义的商店的一部分。

Answer 2

我认为您所需要了解的不是“什么是最新技术”，而是“使用React和Redux进行发布和订阅的规范方法是什么”。

简短的答案是，如果您有足够复杂的应用程序，则应组织商店，以便将应用程序状态划分为slices，并使用container pattern来区分发布和订阅的责任。这样，您就可以避免所提到的问题，即您不知道代码库中的哪些内容正在更改存储以及对更改所做的响应。您可以查看一个容器组件，并查看其如何处理其子组件的UI事件并产生状态更改事件。或者，您可以看到容器如何处理状态更改，然后向下钻取层次结构。如果您可以让Redux slice成为单个容器的职责，那么考虑事件就容易得多。所有其他组件本身都不订阅事件，而是从容器组件发出的props中接收它们需要呈现的更改。并且它们通过props传递的回调通知容器组件自己的事件，因此容器可以发布它们。这可能会走很长一段路，如果您觉得需要传递道具太多级别，可以使用React.children来使嵌套变平一点，或者在极少数情况下使用。

更长的答案有点困难，因为在谈论React时，发布和订阅并不是很有意义。 React应该最终负责渲染。如您所述，并非所有事件都是UI事件。但是，如果您对事物进行建模，使您可以发布和订阅的所有事件都归结为更改商店或对商店更改做出反应，那么您可以将应用程序构建为更专注于Redux。管理您正在谈论的查询和结果应该在没有React的简单JavaScript模块中完成。然后，您可以使用容器组件将商店粘贴到该模块。

人们还使用其他模式，例如动作创建者和选择者。这样做很好，因为至少是要让代码库熟悉。但是事情仍然发展得很快，随着React向Hooks API和React-Redux trying to catch-up迈进。但是切片和容器组件并没有到处走，它们是分离关注点的自然方法。

React / Redux：事件-最新状态

2 个答案: