Consider adding an option to remove immer

[mshindal]

I like this library, but I want to use it without immer.

• It's confusing to newcomers when they read everywhere online that they shouldn't mutate state in Redux, only to see the state being mutated here

• It's inconsistent with React, where you shouldn't mutate state directly

• The pitfalls of immer means it actually adds more complexity. E.g. you have to remember to either mutate directly or return a new state but not both.

Please consider adding an option to remove it.

[markerikson]

Sorry, but no. The explicit point of this library is to make the default use cases simpler. If you don't want to use Immer, don't use createReducer or createSlice (or, just write normal immutable logic by hand as you always have). There are plenty of non-Immer alternatives for writing reducers.

I agree that the teaching aspect makes things more complicated, but that's a tradeoff I think most folks are happy with.

[mshindal]

How is it simpler if you have to remember "I mutated the state, better not return a new object here" every time you write a reducer?

[markerikson]

Because if you're using RSK, that's generally the pattern you should be following, and Immer will warn or throw errors if you mess up.

As I said: half the point of RSK is to use Immer. If you don't want to use Immer, don't use RSK, or don't mutate in the reducers.

[yash-saini275]

@markerikson I have a question and also a suggestion to make immer js optional.
Question: - What is the performance impact of immer js on the processing of the redux logic?

If there is a significant performance impact on processing, then immer js can be made optional so that the developer have to make sure that state is updated not mutated.

[phryneas]

This has been discussed multiple times. You will not have any significant performance issues unless you read or write tens of thousands of times in a single reducer, and in that case you can just use original(state) once to get the original state and return a new object, in which case immer will not cause any performance impact at all.

We will not change this, it is not up for discussion.

[markerikson]

@yash-saini275 Per the perf question, see https://immerjs.github.io/immer/docs/performance .

Beyond that, this has been extensively discussed in #242 , and as Lenz said, this is non-negotiable - we are not changing Immer or making it configurable.