Often when code splitting, it's necessary to lazily add reducers. I haven't used easy-peasy yet, so if there is an idiomatic way, a quick doc update would be great!
I would be interested to hear peoples cases for introducing this feature. Personally I don't feel like the added complexity is warranted merely to save on a few upfront kilobytes.
I don't want to discredit what may be a useful feature to others, but I would definitely appreciate a pragmatic explanation of why it is needed.
We have a production application that has 1000's of actions, 100s of reducers, 100s of effects, etc (this is why this lib is so attractive for managing boilerplate) but it amounts to far more than just a few KB (especially effects which can have complicated code, depend on extra dependencies (different apis, different 3rd party libs), etc which you definitely don't want on first load). You can still push the complexity to the developer but a simple construct like:
const store = createStore({...});
// Probably not the best name, but simply merges the items with the current store and you're ready to rock n' roll.
const newStore = store.mergeWith({
feature: {
data: ['Foo'],
add: (state, payload) => state.feature.data.push(payload)
}
});
In my app, i use one redux store per route so code splitting is not my main concern.
I'd love to hear better idea on this one too.
Is route-splitting with 1 redux store per route enough ? I found it simple to work with.
FYI, now that I feel the API has started to settle and we have recommendations for testing, I have started to give this issue some thought. I have some ideas brewing. I'll post some API ideas soon'ish.
We have an internal admin site with a couple dozen sub-applications. Not all users have access to all apps. They are all code-split and we patch the reducer when each sub-app is loaded. I quite like your API otherwise but this is a stumbling block for us.
This is making its way into v2 馃憤
Most helpful comment
We have a production application that has 1000's of actions, 100s of reducers, 100s of effects, etc (this is why this lib is so attractive for managing boilerplate) but it amounts to far more than just a few KB (especially effects which can have complicated code, depend on extra dependencies (different apis, different 3rd party libs), etc which you definitely don't want on first load). You can still push the complexity to the developer but a simple construct like: