Computing Derived Data
Reselect is a simple library for creating memoized, composable selector functions. Reselect selectors can be used to efficiently compute derived data from the Redux store.
Motivation for Memoized Selectors
Let's revisit the Todos List example:
containers/VisibleTodoList.js
In the above example, mapStateToProps
calls getVisibleTodos
to calculate todos
. This works great, but there is a drawback: todos
is calculated every time the component is updated. If the state tree is large, or the calculation expensive, repeating the calculation on every update may cause performance problems. Reselect can help to avoid these unnecessary recalculations.
Creating a Memoized Selector
We would like to replace getVisibleTodos
with a memoized selector that recalculates todos
when the value of state.todos
or state.visibilityFilter
changes, but not when changes occur in other (unrelated) parts of the state tree.
Reselect provides a function createSelector
for creating memoized selectors. createSelector
takes an array of input-selectors and a transform function as its arguments. If the Redux state tree is changed in a way that causes the value of an input-selector to change, the selector will call its transform function with the values of the input-selectors as arguments and return the result. If the values of the input-selectors are the same as the previous call to the selector, it will return the previously computed value instead of calling the transform function.
Let's define a memoized selector named getVisibleTodos
to replace the non-memoized version above:
selectors/index.js
In the example above, getVisibilityFilter
and getTodos
are input-selectors. They are created as ordinary non-memoized selector functions because they do not transform the data they select. getVisibleTodos
on the other hand is a memoized selector. It takes getVisibilityFilter
and getTodos
as input-selectors, and a transform function that calculates the filtered todos list.
Composing Selectors
A memoized selector can itself be an input-selector to another memoized selector. Here is getVisibleTodos
being used as an input-selector to a selector that further filters the todos by keyword:
Connecting a Selector to the Redux Store
If you are using React Redux, you can call selectors as regular functions inside mapStateToProps()
:
containers/VisibleTodoList.js
Accessing React Props in Selectors
So far we have only seen selectors receive the Redux store state as an argument, but a selector can receive props too.
For this example, we're going to extend our app to handle multiple Todo lists. Our state needs to be refactored so that it holds multiple todo lists, which each have their own todos
and visibilityFilter
state.
We also need to refactor our reducers. Now that todos
and visibilityFilter
live within every list's state, we only need one todoLists
reducer to manage our state.
reducers/index.js
reducers/todoLists.js
The todoLists
reducer now handles all three actions. The action creators will now need to be passed a listId
:
actions/index.js
components/TodoList.js
Here is an App
component that renders three VisibleTodoList
components, each of which has a listId
prop:
components/App.js
Each VisibleTodoList
container should select a different slice of the state depending on the value of the listId
prop, so we'll modify getVisibilityFilter
and getTodos
to accept a props argument.
selectors/todoSelectors.js
props
can be passed to getVisibleTodos
from mapStateToProps
:
So now getVisibleTodos
has access to props
, and everything seems to be working fine.
But there is a problem!
Using the getVisibleTodos
selector with multiple instances of the visibleTodoList
container will not correctly memoize:
containers/VisibleTodoList.js
A selector created with createSelector
only returns the cached value when its set of arguments is the same as its previous set of arguments. If we alternate between rendering <VisibleTodoList listId="1" />
and <VisibleTodoList listId="2" />
, the shared selector will alternate between receiving {listId: 1}
and {listId: 2}
as its props
argument. This will cause the arguments to be different on each call, so the selector will always recompute instead of returning the cached value. We'll see how to overcome this limitation in the next section.
Sharing Selectors Across Multiple Components
The examples in this section require React Redux v4.3.0 or greater
In order to share a selector across multiple VisibleTodoList
components and retain memoization, each instance of the component needs its own private copy of the selector.
Let's create a function named makeGetVisibleTodos
that returns a new copy of the getVisibleTodos
selector each time it is called:
selectors/todoSelectors.js
We also need a way to give each instance of a container access to its own private selector. The mapStateToProps
argument of connect
can help with this.
If the mapStateToProps
argument supplied to connect
returns a function instead of an object, it will be used to create an individual mapStateToProps
function for each instance of the container.
In the example below makeMapStateToProps
creates a new getVisibleTodos
selector, and returns a mapStateToProps
function that has exclusive access to the new selector:
If we pass makeMapStateToProps
to connect
, each instance of the VisibleTodosList
container will get its own mapStateToProps
function with a private getVisibleTodos
selector. Memoization will now work correctly regardless of the render order of the VisibleTodoList
containers.
containers/VisibleTodoList.js
Next Steps
Check out the official documentation of Reselect as well as its FAQ. Most Redux projects start using Reselect when they have performance problems because of too many derived computations and wasted re-renders, so make sure you are familiar with it before you build something big. It can also be useful to study its source code so you don't think it's magic.