Method to turn off freezing when using immer with useSelector()?

[njradford]

Is there a method to allow data being read from redux with useSelector to not be wrapped in an immer wrapper? The behavior it offers in the reducers is welcome but I'm noticing that since you can't add properties to frozen objects, developers will often use nested spreads in their views before dispatching an action.

[markerikson]

There's a couple different answers here.

First, Immer technically does export a way to disable freezing, with setAutoFreeze: https://immerjs.github.io/immer/freezing

However, I'd strongly recommend leaving that as-is. It not only catches bugs and prevents accidental mutations, the dev mode middleware rely on checking for frozen state as a bailout signal to speed up those checks.

Beyond that, it sounds like the frozen state is actually doing its job here. Developers shouldn't be "adding properties to objects", because those are the original objects from state. Adding properties to those objects would be an actual mutation, which is wrong.

It also sounds like this situation involves devs "calculating new state" first, and putting that new state into the action. Instead, we recommend letting the reducer do all that new state calculation work, and keeping the action as minimal as possible:

• https://redux.js.org/style-guide/style-guide#put-as-much-logic-as-possible-in-reducers
• https://redux.js.org/style-guide/style-guide#model-actions-as-events-not-setters

[phryneas]

If you select an item from the store, you get a reference to that store value. If you modify that, you actually edit your store life.

The thing is that in Redux, you are only allowed to edit the store in a Reducer, but nothing hinders you from doing so outside - you just proably have bugs as a consequence. That is why now the freezing is in place to prevent those accidental state mutations. Essentially this is just surfacing a bug you had before.

I would not "deep clone" anything outside of a reducer in 99% of the cases to be honest. That can only result in race conditions and stale values being written back to the store. Send the information about the change as an action to the store and make the change in the reducer.

[markerikson]

I could also have a wrong assumption that the data read from getState is safe to mutate because only a dispatch can change it.

No, this is absolutely wrong! It has never been safe to mutate the Redux state. As Lenz said, getState() just returns a reference to the existing state. It doesn't make any defensive copies - it's exactly what was returned by your root reducer. If you mutate the state outside of a reducer, you are mutating the real state!

Please don't do that :)

Deep cloning is also not the correct answer here. A proper immutable update is more like a "nested shallow clone", where only the paths of the values that need to change are copied. Making a deep clone is A) unnecessary, B) overly expensive perf-wise, and C) will cause way more of your UI to re-render than is needed.

In contrast, putting update logic in reducers means:

• That more of your logic is in pure functions and easily testable
• You know where the state update logic actually lives
• You can take advantage of Immer for "mutating" state update syntax

[njradford]

I would not "deep clone" anything outside of a reducer in 99% of the cases to be honest. That can only result in race conditions and stale values being written back to the store. Send the information about the change as an action to the store and make the change in the reducer.

Thank you for sharing this. For my curiosity, would you be able to illustrate how a race condition would happen there. I won't be adopting more deep cloning either way, just wondering how that situation plays out.

No, this is absolutely wrong! It has never been safe to mutate the Redux state. As Lenz said, getState() just returns a reference to the existing state. It doesn't make any defensive copies - it's exactly what was returned by your root reducer. If you mutate the state outside of a reducer, you are mutating the real state!

The thing is that in Redux, you are only allowed to edit the store in a Reducer, but nothing hinders you from doing so outside - you just proably have bugs as a consequence. That is why now the freezing is in place to prevent those accidental state mutations. Essentially this is just surfacing a bug you had before.

Thank you both for keeping me honest here. I had assumed there was a copy being made under the hood but testing in a non RTK app illustrates what you mean. I'm definitely able to add new properties and see them on the next getState().

state = store.getState()
// {}
state.test = "howdy"
store.getState()
// { test: "howdy" }

I hadn't ever directly mutated state that originated from redux before and incorrectly assumed it was not providing the direct reference. Currently we don't directly mutate redux data anywhere in our react apps, I just wanted to be able to explain in a code review why someone couldn't. Both of your explanations make perfect sense and help point out that there aren't as many non-immer safe guards as I thought.

I also noticed that in previous apps we would have been using connect() from react-redux. Meaning that data is fed in as a prop and marked as read only and you get a run time error for trying to set a property. Whereas with the hook useSelector(), the data isn't considered a prop. Because of that, without immer or in a non RTK app, the bug you note is even more prominent because a user is sidestepping React's ability to notice the data is read only. That definitely makes immer seem even more useful so that data that isn't technically a prop in a react app (because it's coming from a hook) is still considered read only.

[phryneas]

To my knowledge, React has never provided such a safeguard. I've had those bugs back in 2017.

Thank you for sharing this. For my curiosity, would you be able to illustrate how a race condition would happen there. I won't be adopting more deep cloning either way, just wondering how that situation plays out.

Assume you make this a pattern, and as with all patterns, it evolves.
So

const copy = deepCopy(stateValue)
copy.foo.bar = "baz"
dispatch({ type: "x", payload: copy })

becomes

const copy = deepCopy(stateValue)
copy.foo.bar = await something()
dispatch({ type: "x", payload: copy })

now, something() takes two seconds to finish. And in the meantime, an action is dispatched that changes the original stateValue - let's say stateValue.unrelated.

Now, for a second stateValue.unrelated changes. Then something finishes, your action sends the deep copy with the old value of stateValue.unrelated back to the store, and that writes that back.

stateValue.unrelated starts flip-flopping due to a race condition.

[njradford]

Perfect explanation. Thank you!