Advantage of Reselect over container component - reactjs

Question

https://redux.js.org/recipes/computing-derived-data describes how to use reselect createSelector() to avoid unnecessary updates when a component depends on properties that are computed values.
An alternative seems to be to move the necessary computations into a (hopefully) lightweight container component that is connected to the store instead. In this case mapStateToProps() would return references to the store and connect() would not trigger an update of the container component unless the relevant values in the store has changed:
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
Are there any reasons for preferring reselect over a connected container component? I don't find (m)any examples discussing the above approach.

Answer 1

What if you need to use getVisibleTodos in more than one container?
Selectors decouple your containers from the store. When the store shape changes, you only need to update selectors to get the containers in working order.
For this reason, some would advocate placing selectors alongside the reducers.
Selectors are also useful during testing, allowing you to make assertions in terms of domain logic rather than storage logic. This makes tests less brittle.
It's useful to think of the selectors and actions as two halves of your public store API, and everything else as implementation details that are prone to change.

Answer 2

Also, for many simple cases (like your filtering example) you might want to choose a more humble memoizer function over the more ceremonious setup for 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),
})
Pros:
More concise code
Faster than createSelector (Less internal overhead)
Cons:
Less separation between mapSateToProps and the shape of the redux state
I personally tend to keep both createSelector and a memoize function at hand, and choose between them on a case by case basis.