In Resetting Redux State we’ve seen a way to reuse reducer logic to reset the state by creating a root reducer. But that’s not the only way to reuse reducer logic, and higher-order reducers come into the scene to help us with reusability and reducing code duplication.
Higher-order reducers, unlike the root reducer approach, allow us to apply a certain functionality to the reducers that need it. They do so using functional composition, so let’s first learn that concept.

Higher-Order Function
A higher order function is a function that returns another function as its result. For example, if we have a plain function with the following two arguments:
const greet = (first, second) => console.log(first + second)
greet('Hi ', 'little kitty'); // Hi little kitty
We could re-write it in a higher-order function by separating their arguments in two nested functions:
const greet = first => second => console.log(first + second)
greet('Hi ')('little kitty'); // Hi little kitty
Notice the call to greet('Hi ')
function, which returns a function that we are calling as ('little kitty')
. The point is, this approach allow functional composition for code reuse.
Why doing that, you say? Imagine you want to use the greet
function to say Hi ${someone} several times in your code. If you do it with a simple plain function as the first example, you’ll need to repeat Hi
several times:
greet('Hi ', 'dolphin');
greet('Hi ', 'camel');
greet('Hi ', 'snake');
While using a higher order function, we have the ability to easily create a sayHi
function:
const sayHi = greet('Hi ');
sayHi('dolphin 🐬');
sayHi('camel 🐫');
sayHi('snake 🐍');
You can already see two benefits:
- We’re creating a more semantic
sayHi
function based on a more generic one - We’re not repeating
'Hi '
Of course, this is a simplistic example that’s merely for education purposes, but that greet
function could be something which performs heavier logic, where the mentioned benefits will be much more obvious.
Higher-Order Reducers
Now you understand the mechanics of a higher-order function, you might be wondering: how’s that related to reducers? Well, if you think about it, a reducer is simply a function, so when we apply this pattern to reducers we call them higher-order reducers.
Let’s go over an example. Imagine that you have a users and articles reducers, which have a data
property that comes from an API. Something like:
const defaultState = {
data: []
};
const userReducer = (state = defaultState, action) => {
//...
}
Say that both of the users and articles need to have pagination. Then we’ll need to have some actions like GO_NEXT_PAGE
, GO_PREV_PAGE
, UPDATE_TOTAL_PAGES
, etc. It becomes really cumbersome when you need to duplicate all that logic in each of your reducers that need pagination.
Here’s where we can create a higher-order reducer that, given a reducer, returns a decorated reducer with the additional functionality. Let’s call it withPagination
:
const withPagination = reducer => (state, action) => {
switch(action.type) {
case 'GO_NEXT_PAGE':
return { ...state, page: state.page + 1 }
// ...
default:
return reducer(state, action);
}
};
Isn’t this familiar? Yes, the nested function is a reducer. Remember that a reducer has the (state, action)
signature.
What’s happening here is that, based on a reducer
given as an argument, we’re returning a new reducer function that adds the GO_NEXT_PAGE
logic, and on the default
statement of the switch, we simply are proxying the call to the original reducer. So with this, we’re adding some functionality only when needed.
Using a Higher-Order Reducer
We can apply the already created withPagination
higher-order reducer to the reducers we’d like, for example when calling the combineReducers
function to create the app’s root reducer:
import { combineReducers } from 'redux';
import withPagination from './higher-order-reducers/withPagination'
import users from './reducers/users';
import articles from './reducers/articles';
import login from './reducers/login';
const rootReducer = combineReducers({
users: withPagination(users),
articles: withPagination(articles),
login, // we don't need pagination for the login reducer
// ...
});
Notice that we’re applying the pagination logic only to the users
and articles
reducers. That’s the power of higher order reducers: we can apply them as needed.
Parametrizing Higher-Order Reducers
We still have a problem with the previous example: when we trigger the GO_TO_NEXT_PAGE
action, both the users
and articles
will handle that actions since they both are checking the same action name.
As you can guess, that can be solved by specifying different action names for different reducers, so we’ll have the USERS_GO_TO_NEXT_PAGE
and ARTICLES_GO_TO_NEXT_PAGE
actions.
We can make that happen by passing a section parameter to the withPagination
higher order reducer:
const withPagination = (section, reducer) => (state, action) => {
switch(action.type) {
case `${section}_GO_NEXT_PAGE`:
return { ...state, page: state.page + 1 }
// ..
}
};
// ...
const rootReducer = combineReducers({
users: withPagination('USERS', users),
articles: withPagination('ARTICLES', articles),
login
});
Wrapping Up
We’ve seen the higher-order reducer pattern and how it solves code duplication and improves reusability by using function composition.
I hope you’ve learned something new here, and that you can see how there are multiple patterns we can apply to Redux or our code in general given Redux’s functional nature.
Stay cool 🦄