More than one change in state ownership in reduction
I used redux to check how it scales with my application. There are several things that I found as a checkpoint when I used it. There's a good chance that I don't think the redux / method is not using the way it should have been used, or was not reading the document properly. I have read the basic section of this document .
The problem statement is pretty simple. I have two properties in a store
{
x: 10,
y: 20
}
lets say what x
is the x-position of the point and y
is the y-position of the point. There is one condition, if x goes above 50, y becomes equal to x.
So I have this
let x = (state = 10, action ) => {
if (action.type === 'cx') {
return action.value;
}
else {
return state;
}
}
let y = (state = 20, action ) => {
if (action.type === 'cy') {
return action.value;
}
else {
return state;
}
}
let model = redux.combineReducers({x: x, y: y});
let store = redux.createStore(model);
let actions = {
changeX: (val) => {
if ( val > 50) {
store.dispatch(actions.changeY(val));
}
return {type: 'cx', value: val }
},
changeY: (val) => ({type: 'cy', value: val })
}
console.log('INITIAL STATE', '---', store.getState());
store.subscribe(() => {
console.log('SUB2', '---', store.getState());
// Paint the dom with new state
});
So the moment
store.dispatch(actions.changeX(60));
is called a caller function called twice, so a double dom picture happens.
Is there a reduction / workaround method to solve this problem?
source to share
You are trying to treat x
and y
as the same sub-model equation - when one is updated, the other can be updated as well.
Using combineReducer , you can update the corresponding state in the same reducer.
According to the Redux guide , if you want these states to be decoupled sometimes is combineReducer
not enough and you can punch this pattern into a more open reducer .
The combReducers utility included with Redux is very useful, but is deliberately limited to handling one common use case: updating a state tree, which is a simple Javascript object, delegating the job of updating each state slice to a particular slice reducer. It does not handle other use cases, such as the state tree consisting of the Immutable.js Map, trying to pass other parts of the state tree as an additional argument to the slice reducer, or performing "ordering" calls to the slice reducer. It also doesn't matter how a given shear reducer does its job.
So the general question is, "How can I use combReducers to handle these other use cases?" The answer to this is simply "you don't - you probably need to use something else." Once you get past the kernel to use for combReducers, it's time to use a more "custom" logic reducer, be it one-time specific logic or one that might be widely distributed. Here are some suggestions for a few of these typical use cases, but feel free to come up with your own approaches.
An example given for this case:
function combinedReducer(state, action) {
switch(action.type) {
case "A_TYPICAL_ACTION" : {
return {
a : sliceReducerA(state.a, action),
b : sliceReducerB(state.b, action)
};
}
case "SOME_SPECIAL_ACTION" : {
return {
// specifically pass state.b as an additional argument
a : sliceReducerA(state.a, action, state.b),
b : sliceReducerB(state.b, action)
}
}
case "ANOTHER_SPECIAL_ACTION" : {
return {
a : sliceReducerA(state.a, action),
// specifically pass the entire state as an additional argument
b : sliceReducerB(state.b, action, state)
}
}
default: return state;
}
}
source to share