How deep do I need to clone my state when only updating parts of the state? - reactjs

Question

Until recently, I've always just used lodash's cloneDeep to make a copy of my state, then change values and return the cloned state. For example like this:
This would be my initial state:
{
"id": 1213,
"title": "Some title...",
"pages": {
"page1": {
"id": 459,
"title": "Some Page title...",
"fields": {
"field_1": {
"title": "My field",
"type": "text",
"value": "my text value..."
},
"field_2": {
"title": "My field 2",
"type": "text",
"value": "my text two value..."
},
"field_3": {
"title": "My field 3",
"type": "text",
"value": "my text value..."
}
}
}
}
}
Now, I want to update the value of field_2.
My redux reducer would look like this:
import cloneDeep from 'lodash/fp/cloneDeep';
export default function reducer(state, action) {
const {type, payload} = action;
switch (type) {
case 'UPDATE_FIELD_VALUE': {
const { pageIdent, fieldIdent, newValue } = payload;
// This is what I'm doing right now....
const newState = cloneDeep(state);
newState.pages[pageIdent]fields[fieldIdent]value = newValue;
return newState;
// Instead could I do this?
return {
...state,
state.pages[pageIdent]fields[fieldIdent]value = newValue;
}
}
}
}
So, I've read that I don't always have to do deep clone...but in other places I've read that you cannot return the same object, you have to return new objects at all times. So what is the right way to do this?

Answer 1

Yeah, don't do that. Quoting the Redux FAQ on whether you should deep-clone state:
Immutably updating state generally means making shallow copies, not deep copies. Shallow copies are much faster than deep copies, because fewer objects and fields have to be copied, and it effectively comes down to moving some pointers around.
However, you do need to create a copied and updated object for each level of nesting that is affected. Although that shouldn't be particularly expensive, it's another good reason why you should keep your state normalized and shallow if possible.
Common Redux misconception: you need to deeply clone the state. Reality: if something inside doesn't change, keep its reference the same!
So, you don't want "deep clones", you need "nested shallow clones".
Deep-cloning is bad for performance in two ways: it takes more work to clone everything, and the new object references will cause UI updates for data that didn't actually change in value (but the new references make the UI think that something changed).
You should read the Redux docs page on "Immutable Update Patterns". Here's the nested state update example from that page:
function updateVeryNestedField(state, action) {
return {
....state,
first : {
...state.first,
second : {
...state.first.second,
[action.someId] : {
...state.first.second[action.someId],
fourth : action.someValue
}
}
}
}
}
If you find that to be too tedious or painful, you should either change how you structure your state so it's flatter, or you can use one of the many immutable update utility libraries out there to handle the update process for you.

Answer 2

You really shouldn't always do a clone of the state object. Redux shines if you can ensure that:
The only section of state that changes is the section that should change, based on the action provided to the reducer. So if you're updating field_1, nothing about field_2 should change.
If there's a section of state that should change, it always changes. So if your action updates field_2, then the field_2 object reference should change.
This is much easier if your state allows for 'deep' updates. State normalization is one of the better 'patterns' used in redux apps and is described in the docs.
For instance, let's restructure that state of yours a bit (assuming the top level is a book object, and the field IDs are globally unique):
Initial state
"books" : {
"1213": {
"id": 1213,
"title": "Some title...",
"pages: [..., "page1", ...],
}
},
"pages": {
"page1": {
"id": 459,
"title": "Some Page title...",
"fields": [..., "field_1", "field_2", "field_3", ...],
}
},
"fields": {
"field_1": {
"title": "My field",
"type": "text",
"value": "my text value..."
},
"field_2": {
"title": "My field",
"type": "text",
"value": "my text value..."
},
"field_3": {
"title": "My field",
"type": "text",
"value": "my text value..."
}
}
Note that each 'book' entity has a list of page IDs rather than a full objects nested in it. Similarly, each page has a list of field IDs rather than the actual fields. This way all your data-carrying entities are stored at the 'top-level' of state and can be independently updated without touching the entire state.
By flattening your state structure, you can create 'sub-reducers' that are only concerned with a small slice of your state. In the above case, I'd have:
import { combineReducers } from 'redux';
// This reducer handles all actions that affect book entities
const books = (state = {}, action = {}) => state;
// This reducer handles all actions that affect page entities
const pages = (state = {}, action = {}) => state;
// This reducer handles all actions that affect field entities.
// For your problem, this would look like:
const fields = (state = initialFields, action = {}) => {
switch (action.type) {
case 'UPDATE_FIELD_VALUE':
return {
...state,
[fieldIdent]: {
...state[fieldIdent],
value: newValue,
}
}
default:
return state;
}
}
// This results in the state structure above
const reducer = combineReducers({
books,
pages,
fields,
});
In the above code, changing a field has no effect on the page or book entities, which prevents unnecessary re-renders. That being said, changing the field_2 value will definitely result in a new field_2 object, and re-render as necessary.
There are libraries that help with structuring your state like this, from JSON API response data. This is a rather good one: https://github.com/paularmstrong/normalizr
Hope this helps!

Answer 3

I think facebook's immutable js solve all your problems. Read docs here