by mattkrick

mattkrick / redux-operations

Solves challenging redux problems in a clean, understandable, debuggable fasion.

125 Stars 5 Forks Last release: Not found MIT License 49 Commits 6 Releases

Available items

No Items, yet!

The developer of this repository has not created any items for sale yet. Need a bug fixed? Help with integration? A different license? Create a request here:

npm version


Solves challenging redux problems in a clean, understandable, debuggable fasion.


npm i -S redux-operations

What kind of problems can it solve?

Everything you'll ever encounter in the wild: - Dynamic state - Action watching (eg count how many times a particular action was run) - Based on itermediary results (eg 2 reducers sharing the same action & 1 needs the result of the other) - Async actions without thunk/promise middleware. Just write your logic directly in your reducer - Visual, dare I say graphiQL, API to make debugging a breeze

Where can I see it working?

  • Your app here!

How's it different from redux-saga?

Risking oversimplification, redux-saga uses generators and puts business logic in the middleware. It also lets you cancel promises.

redux-operations keeps all logic in the reducer by adding info to

behind the scenes. This allows it to solve a few extra hard problems like dynamic state. It also plays nicely with vanilla redux so you only need to use it for the tricky parts of your app. But, if you like a visual API for debugging, you might as well use it for your whole app.

See scalable-frontend-with-elm-or-redux to see how the two solve the same problem and decide which fits your use case.


Create the store enhancer

Just like

, redux-operations is a


const storeEnhancer = reduxOperations();


import {createStore} from 'redux'
import {reduxOperations} from 'redux-operations';
return createStore(rootReducer, initialState, reduxOperations());

If you use this in conjunction with redux-devtools, you'll see an enhanced state there:

state = {

There's no need to adjust any of your code, your application only sees what's inside


Write your reducer

When your store is created, redux-operations ignores your regular reducers and only uses reducers designed for it. These are easily created by using a reducer factory that takes in an

and an object full of "operations". An operation is an action that is specific to the reducer. In other words, one action type has 1 or many operations. This already occurs in the wild, but the execution order is arbitrary and intermediary results are not passed through. The operationName is the same name that you use in your
. By making you repeat that name here, we allow for perfect compatibility with standard redux.


operationReducerFactory(operationName, initialState, reducerObject);


import {operationReducerFactory} from 'redux-operations';
const initialState = 0;
export const counter = operationReducerFactory('counter', initialState, {
    resolve: (state, action)=> state + 1
    priority: 1, // if this action type is used in another reducer, this determines which runs first
    resolve: (state, action)=> {
      setTimeout(()=> {
        const {dispatch, locationInState} = action.meta.operations;
        // yes, that counter variable below is a circular reference to the reducer object
        const inc = bindOperationToActionCreators(locationInState, counter, increment);
      }, 1000);
      return state;
    resolve: (state, action) => action.payload.newValue, // set the state to the variable passed in
    arguments: {
      newValue: {type: Number, description: 'The new value for the counter'} // show this in the API

Notice that all the logic occurs in the

method, even async actions. In plain redux, this logic is split between the action creator and the resolve function, which subjectively makes the flow harder to follow.

Integrate into the model-view layer (eg your redux container)

redux-operations works with all frontend frameworks, but we'll show an example of it working in react. For the example, imagine you have 2 counters that share the same reducer. You need to know where in the state tree to find each (called

) and the
so it can initialize the state at runtime (for dynamically generated states)

First, we need to get the possibly-dynamic state from the state tree.


walkState(locationInState, state, reducerObject);


import {counterReducer} from './counterReducer';
import {walkState} from 'redux-operations';

const mapStateToProps = (state, props) => { return { // locationInState is static here, but is usually passed in via props. counter: walkState(['counters', 'top'], state, counterReducer); } };

Next, we need to make sure that our action creators attach this info to the new actions. This is done by attaching

and the
to the
property. Since the
is stored in the
, we just pass that in. To make it easy, redux-operations offers a HOF to do the work for you. It takes in a single function or an object of functions, similar to redux's


bindOperationtToActionCreators(locationInState, reducerObject, actionCreators);


import {bindOperationToActionCreators} from 'redux-operations';
import {counterReducer} from './counterReducer';
import * from './actionCreators';
import {connect} from 'react-redux';

@connect(mapStateToProps) export default class Counter extends Component { render() { const {incrementAsync} = bindOperationToActionCreators(['counters', 'top'], counterReducer, actionCreators); return (

) } }

More advanced cases

For more advanced use cases, see the Counter example or read the blog post.

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.