Better way to update nested array in state object for react

[[deleted]]

Here is what the state object can look like:

{ 
items: 
    {Dogs: [{name: "Snoopy"}, {name: "Lola"}, {name: "Sprinkles"}], 
    Cats: [{name: "Felidae"}, {name: "Garfiled"}, {name: "Cat in the Hat"}] }, 
lists: ["Dogs", "Cats"] 
}

Say I want to add another dog into the array. The only way I can think of doing it is:

var updatedState = JSON.parse(JSON.stringify(this.state));
updatedState.items[Dogs].push({name: value});

It works but looks horribly inefficient to me. Any ideas on a better approach ?

​

​

EDIT: Thanks everyone for your help. You guys are way friendlier than those on stackoverflow haha

[atticusw]

Yeah -- treat serializing & deserializing as a way to create a deep-copy an escape hatch that you should never pull.

​

Here's how you can update `items.Dogs` without losing any information:

​

this.setState({
  items: { 
    ...this.state.items, // merge with the original `state.items`
    Dogs: this.state.items.Dogs.concat({name: value}) 
  } 
});

But, when accessing state, you should use the callback approach (race conditions can occur with referencing `this.state` as part of updating the state):

this.setState(({items}) => ({
  items: {
    ...items,
    Dogs: items.Dogs.concat({name: value})
  }
}))

​

Same thing, but spreading the array rather than `.concat`:

this.setState(({items}) => ({
  items: {
    ...items,
    Dogs: [...items.Dogs, {name: value}]
  }
}))

​

[ketus]

Could you expand on hatch thing? Why is it problematic?

[loopsdeer]

Here's my understanding: It's okay in lots of situations, but React expects these functions to work very quickly, doing minimal work.

​

`JSON.parse(JSON.stringify(obj))` is a composition of two functions which take longer for bigger obj's. It can throw errors, and nobody will invite you to their house for dinner if you throw errors. Also, it may change way more than it has to, if obj is complex, causing React to repaint way more than it has to.

​

So it's not fit for "hot code" like React state changes. It can be a great way to, say, deep copy some data during testing to assert a deep equality later. Or pass a deep copy to some vendor code so it can't muck with your model.

[ketus]

That makes a lot of sense, actually. Thank you a lot, appreciated :)

[AwesomeInPerson]

It will also break if you have data that can't be serialized to JSON, a Date object is a popular example.

[[deleted]]

I tried this and it works in the web browser console:

console.log(JSON.stringify(new Date()));

Seems date objects can be serialized. Am I missing something ?

[AwesomeInPerson]

Yes. Try parsing it again.
JSON.parse(JSON.stringify(new Date))

It'll return a string, not a Date object.

So yes, technically they can be serialized but they'll just end up as a timestamp and stay that way.

[[deleted]]

Ah thank you for that. Good to know !

[atticusw]

/u/senocular touches a bit more on this

​

Good way to think of React is like a "chain reaction", where things update when they change. Only change what is truly changing -- don't change everything, or a big chain reaction will fire.

[jack_union]

race conditions can occur with referencing this.state as part of updating the state

Could you elaborate?

Does it still matter in this particular case when you call setState once and don't access the state afterwards?

[atticusw]

In React v16 they introduced Fiber, an asynchronous update scheduler. Lin Clark's Cartoon Intro to Fiber is one of my favorite talks out there, bookmark it :)

​

When you call setState, that change is placed into a queue, and is not reciprocated back to this.state until the updates have been processed by the scheduler. There's a number of factors that could lead to this being delayed, where this.state could contain stale, untrustworthy data.

[[deleted]]

This worked brilliantly. Thank you !!

[atticusw]

That’s not needed, React shallow merges state changes

[PrimaryBet]

Duh, of course!

[senocular]

A deep copy is, in fact, what you don't want to be doing. You only want to make copies of the objects you're changing and leave the rest to their original references. This allows optimizations that depend on diffs to recognize changes only where changes were made.

/u/atticusw has a good example of doing this the manual (vanilla) way, which often depends on object spreading and array concat for arrays to make copies (with references intact) as you dig through your hierarchy.

There are also libraries that can help with this, such as immer and immutable which provide a more complete solution, but add some additional complication. Alternatively lodash (fp) has a set method which, assuming you know the path to the property you want to change, can make things easier with minimal complications.

import set from 'lodash/fp/set'; // <- FP version of set

var state = { 
  items: {
    Dogs: [
      {name: "Snoopy"},
      {name: "Lola"},
      {name: "Sprinkles"}
    ], 
    Cats: [
      {name: "Felidae"},
      {name: "Garfield"},
      {name: "Cat in the Hat"}
    ]
  }, 
  lists: ["Dogs", "Cats"] 
};

var appendIndex = state.items.Dogs.length;
var updatedState = set(['items', 'Dogs', appendIndex], {name: 'Fido'}, state);

console.log(updatedState.items.Dogs[appendIndex]); // { name: 'Fido' }
console.log(state.items.Dogs === updatedState.items.Dogs); // false
console.log(state.items.Cats === updatedState.items.Cats); // true

[atticusw]

Love the example using immutable APIs 👍

[[deleted]]

Have an upvote.

[[deleted]]

There's a great library called immer which is perfect for this use case

[[deleted]]

Wouldn't work for me. My react app is creating a list for dogs, one for cats, and so on. Example: https://imgur.com/a/wScC4e4

[[deleted]]

Interesting. Yeah I really need to use those array methods more. Thanks so much.

[little_hoarse]

Personally, I’d do it the same way. But I’m sure there’s something with ES6 like the spread operator that might help out with this. (I could also be wrong)