Should the `state` object be modified directly?

I remember watching some Dan Abramov video about redux or something, and there was a bit about not mutating the state, but always returning a copy of it.

So I’m doing this in my app:

return Object.assign(state, {selectedIndex: --state.selectedIndex})

But should I just be modifying the state directly? Does it matter?

state.selectedIndex--
return state

[zeke]

Sorry @yoshuawuyts but I don’t fully understand your explanation.

under the hood we take the changes and run xtend() on it to turn it into a new state

Does this mean the state argument I receive in the reducer function is actually a copy of the “real” state object? In other words, what is the first argument to xtend “under the hood”?

Under the hood we’re also calling Object.freeze()

What exactly is being frozen? It must not be the state argument, as it appears that I can make changes to that directly without anything breaking. From the demo:

// original
increment: (data, state) => ({count: state.count + 1})

Can be changed to this and everything works:

// mucking with the state object
increment: (data, state) => {
  state.count+=3 // modify the state
  state.foo='yay' // even add some new properties
  return state
}

I also tried adding use strict for grins and didn’t see any exceptions.

there’s a way to converge mutation with reduced side effects and get great performance

What does this mean?

I’m basically asking for clarification on everything you just said! 🙈

Once I see the light, I will try to make it worth your while by opening a PR with some helpful documentation on this topic.

[Ryuno-Ki]

Sine objects are passed by refernce it matters. If you touch the state object you’ll have side effects. Which is against the functional programming/Redux philosophy.