https://redux.js.org/recipes/computing-derived-data描述了当组件依赖于计算值的属性时,如何使用重新选择createSelector()来避免不必要的更新。
另一种选择似乎是将必要的计算转移到(希望)轻量级的容器组件中,而该组件又连接到商店。在这种情况下, mapStateToProps()将返回对商店的引用, connect()不会触发容器组件的更新,除非商店中的相关值发生了变化:< / p>
import { connect } from 'react-redux'
import { toggleTodo } from '../actions'
import TodoList from '../components/TodoList'
const mapStateToProps = state => {
return {
visibilityFilter: state.visibilityFilter,
todos: state.todos,
}
}
const mapDispatchToProps = dispatch => {
return {
onTodoClick: id => {
dispatch(toggleTodo(id))
}
}
}
const connected = connect(
mapStateToProps,
mapDispatchToProps
)
const getVisibleTodos = (todos, filter) => {
switch (filter) {
case 'SHOW_ALL':
return todos
case 'SHOW_COMPLETED':
return todos.filter(t => t.completed)
case 'SHOW_ACTIVE':
return todos.filter(t => !t.completed)
}
}
const VisibleTodoList = connected((props) => {
return <TodoList
todos={getVisibleTodos(props.todos, props.visibilityFilter)}
onTodoClick={props.onTodoClick}
/>
})
export default VisibleTodoList
是否有任何理由希望重新选择而不是连接的容器组件?我没有找到(m)讨论上述方法的任何例子。
答案 0 :(得分:0)
如果您需要在多个容器中使用getVisibleTodos
该怎么办?
选择器将您的容器与商店分离。当商店形状发生变化时,您只需更新选择器即可使容器处于正常工作状态。
For this reason, some would advocate placing selectors alongside the reducers.
选择器在测试期间也很有用,允许您根据域逻辑而不是存储逻辑进行断言。这使得测试不那么脆弱。
将选择器和操作视为公共存储API的两半以及其他所有可能更改的实现细节非常有用。
答案 1 :(得分:0)
此外,对于许多简单的情况(例如您的过滤示例),您可能希望在createSelector()
的更为隆重的设置中选择更简陋的记忆功能:
const selectVisibleTodos = memoize(getVisibleTodos)
const mapStateToProps = state => ({
todos: selectVisibleTodos(state.todos, state.visibilityFilter),
})
VS
const selectVisibleTodos = createSelector(
(state) => state.todos,
(state) => state.visibilityFilter,
getVisibleTodos
)
const mapStateToProps = state => ({
todos: selectVisibleTodos(state),
})
<强>优点:强>
createSelector
更快(内部开销更少)<强>缺点:强>
mapSateToProps
与redux state
我个人倾向于同时保留createSelector
和memoize
功能,并根据具体情况在它们之间进行选择。