selector-action greatly simplifies a common Redux pattern: actions whose values depend on the current Redux state. This is especially common with async actions, for example, when reloading some data with an API call:
// The active ID is in the Redux state, but we need it to make our API call. Sad!
export function reloadActiveItem(activeId) {
return {
type: 'RELOAD_ACTIVE_ITEM',
promise: fetch(`//website.com/items/${activeId}`),
};
}
In this example, we have to pass in the active ID to our action even though it’s actually available
as part of the Redux state! This pollutes our React components with unnecessary props, and makes
the actions themselves more complicated than they need to be. We could make this a little
nicer with redux-thunk
:
export function reloadActiveItem() {
return (dispatch, getState) => {
// Clever clever! We can access the current state by returning a thunk.
const state = getState();
const activeId = activeIdSelector(state);
// Now we just have to dispatch the action...
return dispatch({
type: 'RELOAD_ACTIVE_ITEM',
promise: fetch(`//website.com/items/${activeId}`),
});
};
}
This is already a lot better! However, if you do this enough times, you'll notice that there's a lot
of boilerplate here. There's even more boilerplate when you’re testing this action creator: you need
to mock getState
so that your selectors return the right values, then spy on dispatch
to make
sure that the right action is being dispatched.
Let's simplify this contrived example by using selectorAction
. Instead of doing the dispatching
and the action-creating ourselves, we’ll pass in a the selector and an action creator that uses
the selector's results.
import selectorAction from 'selector-action';
// ...
export const reloadActiveItem = selectorAction(
activeIdSelector,
activeId => ({
type: 'RELOAD_ACTIVE_ITEM',
promise: fetch(`//website.com/items/${activeId}`),
}),
);
As you can see, this looks a lot like the syntax of Reselect. You pass in one or more selectors, then an action creator that takes the selectors’ return values as its arguments. The result of the action creator function is what's dispatched.
To make testing easier, selectorAction
exposes the original action creator as an
originalActionCreator
property of the generated function. This allows for testing the
underlying action creator without using a fake state or stubbing dispatch
.
describe('reloadActiveItem', () => {
it('returns an action with the correct type', () => {
const activeId = 1234;
const action = reloadActiveItem.originalActionCreator(activeId);
expect(action.type).to.eql('RELOAD_ACTIVE_ITEM');
});
});
Note: Behind the scenes, selectorAction
relies on redux-thunk
to access the store’s dispatch
and getState
functions . This means you still need to use redux-thunk
as a middleware when using
this library.
In addition to the results of the selectors, state
is passed in as the last argument to the action
creator. If you don't specify any selectors, then state
is the only argument. This can be useful
for converting actions that already use the getState
trick shown above.
export const reloadActiveItem = selectorAction((state) => {
const activeId = activeIdSelector(state);
return {
type: 'RELOAD_ACTIVE_ITEM',
promise: fetch(`//website.com/items/${activeId}`),
};
});
Like Reselect, you can pass in an array of selectors instead of passing them as separate arguments. Here is an even more contrived example demonstrating this fact.
export const awesomeAction = selectorAction([
fooSelector,
barSelector,
], (foo, bar) => ({ type: 'AWESOME!', payload: { foo, bar } }));
You may run across a case where an action creator needs a mix of selector results and
regular arguments to compute an action. For instance, let’s say that the user has entered a new name
for the current active item. Your reducer will need both the new name AND the active item’s ID
to compute a new state. Using selectorAction
, you can create an action like this using a
higher-order function:
export function setActiveItemName(newName) {
return selectorAction(activeIdSelector, activeId => ({
type: 'SET_ITEM_NAME',
payload: { activeId, newName },
}));
}
This works because selectorAction
normally returns a generated action creator that takes no
arguments. However, if it is called with dispatch
and getState
as args, then it will return
a thunk action instead.
MIT