This is a pattern we don鈥檛 encourage to use all the time, but sometimes it鈥檚 handy.
We should really include it in the FAQ, or better, write a recipe.
Also I still think this shouldn鈥檛 be the default behavior for combineReducers(). The whole point is you do this explicitly and structure data dependencies any way you like:
export default function todos(state = {}, action) {
return {
byId: byId(state.byId, action, state),
listedIds: listedIds(state.listedIds, action, state)
}
}
or
export default function todos(state = {}, action) {
var nextById = byId(state.byId, action, state.listedIds);
var nextListedIds = listedIds(state.listedIds, action, nextById);
return {
listedIds: nextListedIds,
byId: nextById
}
}
or
export default function todos(state = {}, action) {
var nextListedIds = listedIds(state.listedIds, action, state.byId);
var nextById = byId(state.byId, action, nextListedIds);
return {
listedIds: nextListedIds,
byId: nextById
}
}
The order is up to you, depending on your needs.
Writing a "Structuring Reducers" recipe page is still on my to-do list. Might have time to take a first crack at it this weekend. We'd then be able to add a link to it in the "sharing state" FAQ question.
Some month ago I wrote a micro-module to perform this task and combine reducers specifying their dependencies, turned out that this is mostly a rare case. Turns out it's handy but using side-effects handling could achieve the same result.
https://github.com/KodersLab/topologically-combine-reducers
@mattiamanzati That鈥檚 a neat module 馃槃 .
Covered in http://redux.js.org/docs/recipes/reducers/BeyondCombineReducers.html#sharing-data-between-slice-reducers , and also mentioned in http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/#update-logic-and-data-flow-are-explicit .
Most helpful comment
Writing a "Structuring Reducers" recipe page is still on my to-do list. Might have time to take a first crack at it this weekend. We'd then be able to add a link to it in the "sharing state" FAQ question.