Interop with existing redux store

Hi there, great library!

I read through the docs and found https://easy-peasy.now.sh/docs/recipes/usage-with-react-redux.html but the given example replaces the top level Provider’s store with a new easy-peasy store.

We’ve got an large existing redux store, and wanted to begin migrating to easy-peasy by having easy-peasy control a subtree of that store. Is that possible? Thanks!

[allpro]

I have successfully integrated Easy-Peasy (EP) with ordinary Redux actions and reducers. The method I used is a reducerEnhancer, which is a store-config option in EP. This helper (below) runs every action through both the ordinary root-reducer (legacyRootReducer) and the EP root-reducer that’s passed-in (epRootReducer) …

const reducerEnhancer = epRootReducer => (
    (prevState, action) => {
        let nextState = prevState
        nextState = legacyRootReducer(nextState, action)
        nextState = epRootReducer(nextState, action)
        return nextState
    }
)

const store = createStore(model, {
    name: 'Test Store',
    reducerEnhancer
})

Demonstration Repository

The Easy-Peasy Test App I created (using CRA) is on GitHub. If you want to do your own testing, pull it and then run npm install and npm start. Use Redux Dev-Tools to see what’s happening when you click the test-buttons. https://github.com/allpro/easy-peasy-tester

combineReducers Issues

The ordinary rootReducer is created with the combineReducers helper. This can cause problems because it ignores/deletes any top-level ‘key’ that does not exist in its own configuration. This means keys that exist only in EP models get deleted! combineReducers logs these keys in the console so it’s easy to debug.

The simple solution is to add dummy-keys for domains/keys that exist only in EP. This prevents combineReducers from deleting them. Here is what that looks like in my test app…

const dummyReducer = state => state || {}

export default combineReducers({
    posts,
    albums,
    // Add dummy keys for Easy-Peasy root-keys.
    // This prevents combineReducers from ignoring/deleting these keys.
    list: dummyReducer
})

Overlapping Functionality

I tested having the same data-keys, thunks and actions specified in both EP and ordinary Redux. This works fine. Since the two instances use different action-names (by default), only one reducer is run for each action, so there is no duplication. However, EP can dispatch an action-name to be handled by an ordinary reducer, and visa-versa. This means the two systems can inter-operate easily, and code can be transitioned to EP one action or reducer at a time.

Middleware Integration

EP already adds redux-thunk middleware, so if you are using this you don’t even need to import it anymore! Other middleware can be added, but I didn’t need to - yet.

My next test will be with Redux Saga middleware because that’s what I need to integrate with. I’m hopeful that will not be a problem. Stay tuned!

UPDATE 2019-07-11

I’m now using this pattern in a production app that uses multiple middleware, including:

• redux-thunk (existing code uses the version added by Easy-Peasy)
• redux-saga
• redux-batch-middleware
• Custom api-integration middleware

All middleware works as normal - the existing Redux code requires no modifications. The two systems work fine together.

I did need to modify the old code that hot-loaded the ‘root-reducer’ in development. This was simple though - see the separate hot-loading issues or the docs for details on this.

[mcamac]

Thank you both!