_.clone(state) or _.cloneDeep(state.prop)

[Diwei-Chen]

Thank you for all your help @JulianKingman

I may be wrong, but as far as i know, the previous state is suggested to stay unchanged but _.clone is a shallow copy of the state :

var objects = [{ 'a': 1 }, { 'b': 2 }]; 
var shallow = _.clone(objects);
console.log(shallow[0] === objects[0]);
// => true

ref: https://lodash.com/docs/4.17.4#clone

So when we are mutating newState, are we mutating the previous state?

For example, if we are gonna modify the resources property of state, I would suggest:

newState = _.clone(state);
newRes = _.cloneDeep(state.resources);
newState.resources = newRes;
return newState;

which will distinguish the previous state and the new state, and tell the store that the resources property have been changed.

This may also raise the issue of #35 , i.e. persist-redux thinks the state or the property hasn't been changed, so it won't persist the state or the property to disk.

You might be interested in this discussion:
rt2zz/redux-persist#90

regards,

[Diwei-Chen]

FYI, i did the following tests

const cloneCheck = _.clone(state);
console.log(cloneCheck === state);
// => return false;
console.log(cloneCheck.user === state.user);
// => return true;

const stateCheck = { ...state };
console.log(stateCheck === state);
// => return false;
const propCheck = { ...state };
console.log(propCheck.user === state.user);
// => return true;

const visitedBuzz = _.cloneDeep(state.visitedBuzz);
const tmpCheck = { ...state, visitedBuzz };
console.log(tmpCheck === state);
// => return false;
console.log(tmpCheck.visitedBuzz === state.visitedBuzz);
// => return false;

[JulianKingman]

Hm, so this is a harder problem than it appears on the surface. For whatever reason, using spread operators or Object.assign was causing major performance issues, and clone seemed to mitigate that. I checked out immutable.js, but it seems like that's a one-way-street, which I don't like. Other ideas? Maybe I'll try testing the spread operator again and see if I can get it performing acceptably.

[Diwei-Chen]

I think redux-persist will check each address space of properties to determine if it needs to update the redux state on disk, which is intelligent and is similar to mapStateToProp function in redux, i.e. if the address space of the property changes, it will trigger the component to re-render. So each time if i need to re-render the property, i would reassign a new address space for it by using _.cloneDeep, which could also avoid the other properties being re-rendered, or it would be too heavy. FYI, i asked a question here: rt2zz/redux-persist#356

The spread operators might be doing similar things as clone cos both of them are copying the references. i changed the codes to #37 and it seems like solving the problem. This may also raise a performance issue if the size of a property is too large.

[JulianKingman]

I refactored things again a bit. Destructuring finally clicked a bit more for me, basically you destructure to the level that you want to modify. Things seem to be working OK now, give it a try (I moved away from clone, since it does the same thing as destructuring anyway).