Add Usage Guide page on writing reducers with Immer

Seems like a lot of the questions we get are around how to use Immer-powered reducers effectively. Common issues include:

• How to reset state
• Trying to do state = someValue and thinking that will replace the state
• Debug logging proxies and needing to use current(state)

Definitely worth a docs page that covers these things and more.

Also see #875 for some related thoughts.

Additional notes:

• Can do Object.assign(state, data)
• General examples of mutation, and mixing and matching mutations and immutable logic ( state.items = state.items.filter())
• Mutate or return new state, but not both

[talolard]

Makes sense. I’d like to make one last push for a discussion of these within a “immer and redux” document.

Immer does two great things, it reduces boilerplate related to maintaining immutability AND it allows working with mutable things in a way that is effectively immutable, at least with respect to reference equality.

I think RTK’s approach to immer is “when you use this you’ll have nicer shorter code and less bugs “.

But immer itself says “you can use me to work with maps and sets”

So my first point in favor of a discussion of it in these specific docs is that a reader needs a reconciliation between what redux says and what immer says. Why do the immer folks say “yeah, use Maps, it just works” but the redux folks say “use immer, but don’t use Maps”.

The second reason to include a discussion is that these patterns are immensely useful, and a more nuanced discussion will likely give users “permission “ to experiment and see if they fit in their own workflow. For us, giving up on time travel debugging and persistence was an easy choice because we could express things we really needed very easily with Maps. But we always loved in fear because the redux docs said “just don’t” even though immer says “you can use this stuff, it just works” and it really does.

In other words, probably tens of thousands of people make decisions based on these docs and it’s worth giving them the nuance to make a fully informed choice .

To summarize, I’m not suggesting that redux condone the use of map and friends. But, immer had changed the technical details behind the blanket no. In a discussion of immer and redux, it’s helpful to acknowledge what immer states and map those statements to redux recommendations with enough detail for the end user to make an informed decision

On Sat 20. Feb 2021 at 21:33, Mark Erikson [e-mail] wrote:

There have traditionally been three reasons why we recommend against using class instances and similar values in the Redux state:

• Using them normally implies mutations (myMap.set(someKey, someValue), myClassInstance.field = value, etc), which is not acceptable with Redux
• The mutations also mean that the same instance is in the Redux store, and since React-Redux relies on reference comparisons to determine if something has changed, the UI will not update properly if you select state => state.someInstance
• Classes in general do not serialize properly, including Maps and Sets. That means that they don’t show up right in the Redux DevTools, they don’t restore correctly if you try to persist state via localStorage or similar, and they can cause issues if you try to do time-travel debugging.

That’s not to say that they never work. But there’s enough problem points there that we’ve always made a blanket statement that “you should never do this”, or at least “only even consider this if you realllly know what you’re doing and are willing to accept that things might not work as expected”:

https://redux.js.org/faq/organizing-state#can-i-put-functions-promises-or-other-non-serializable-items-in-my-store-state

I’m not sure exactly how Immer’s support of MapsandSet`s works. It may be that it ends up copying them, which is better than mutating them. But it’s still not a use case we want to encourage.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/reduxjs/redux-toolkit/issues/881#issuecomment-782745386, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABI227VF54VFEXYLIXEMS7TTAAMCJANCNFSM4WTX4AUA .

[talolard]

I know. I always thought that’s forwned upon because those lead to state mutation which is a no-no. But immer solves that. So, when discussing immer, I’d like to know if the official position has changed and why or why not. I think it would be useful to more people than just myself. The official docs say

This ensures that capabilities such as debugging via the Redux DevTools will work as expected. It also ensures that the UI will update as expected.

To which I say 1) Immer makes the UI update as expected 2) The developer convenience I get from sets is greater than what I get from Redux DevTools.

The second point is a tradeoff, which developers can make. The first point is pretty important, I think Immer removed a barrier in state management. So either I’m totally wrong (and probably not the only one) or it’s a fair point and it would be helpful if a discussion of immer touched on way not to use Maps/Sets anyway .